On Tue, 16 Mar 2004, Tim Jenness wrote:
> On Tue, 16 Mar 2004, McIlwrath, BK (Brian) wrote:
>
> > Starlink development wrote on :
> >
> > > one further thing I should have mentioned. Have a look at the
> > > "hds_datestamp" files. You'll see what information HDS has
> > > derived about the native machine types. This is the real source for
> > > PRM's constants.
> >
> > HDS runs a little program to generate this information dynamically on each
> > install.
> >
> > It should indeed match PRIMDAT - and would need much thought before
> > altering!
> >
>
> Okay. So it sounds to me like:
>
> 1. HDS needs to know what a bad value looks like on other machines that
> implement HDS (I assume the bad values are not in the data header itsefl
> and therefore I assume that HDS bad values look the same on all platforms
> modulo a byte swap, since byte counts for each type are fixed)
Hi Tim,
actually my recollection of various discussions is that the signature of
the native format used to write the data is embedded in the file (on an
object basis, Brian?), so HDS just needs to know the local setup and works
out how to convert from the stored format to the native one. So BAD values
can change (actually I think that HDS supports IEEE floating point and VAX
floating point, so in fact in these VAX free days we only byte swap).
> 2. PRIMDAT has to agree with HDS definition of bad value (although it
> seems they come up with their definitions independtly)
Yes, the PRIMDAT values are arranged to be the same.
> 3. C programs need to get their bad values from img.h which assummes
> float.h can provide definitions. [and as Malcolm points out only half of
> the prm.h functionality is there since the minimum float is one bit
> greater than VAL__BADR.]
>
> This would seem to suggest that we should have the bad value definitions
> in a single place and that PRIMDAT should be that place. Would it be
> problematic if HDS started using primdat? (and the HDS routines to
> determine all that great stuff in the HDS datestamp file simply became
> part of primdat)?
It has to be the other way around. PRIMDAT must mirror what HDS uses.
> PS Is the only specification for HDS sitting in hardcopy only on Brian's
> desk? Is there any chance at all that a RAL secretary could type it up in
> electronic form? I don't know about you guys but I get nervous when all
> our software relies on an undocumented format.
Me too.
Peter.
|