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)
2. PRIMDAT has to agree with HDS definition of bad value (although it
seems they come up with their definitions independtly)
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)?
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.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|