Greetings, all.

Primdat is coming along.  I've got most of the platform dependencies
sorted out, I think, so that the only one left is PRM_PAR.  That looks
like a real pig, however, because it seems to have both odd and
non-standard Fortran in it, and some unexplained magic in the declaration
of the bad values.  That, and _two_ ix86_Linux files.  And the comments
explaining what platform the files are for don't always match the files'
naming extensions.  I'm sorely tempted to junk the existing PRM_PAR
files, replace it with a prm.h, and generate PRM_PAR from that.  However,
I'd need to know more about what was in there and why.

I've never consciously used primdat, but I'm hoping that someone else has.

First is the statements initialising reals with hex values:

      REAL VAL__BADR
      PARAMETER ( VAL__BADR = 'FF7FFFFF'X )

I can see what that's doing, but it looks veeeery dodgy.  Can anyone point
to any details about this?  I can't find any support for that syntax
in the Fortran standard, though that's rather confusingly arranged and
I could have missed it, and I'd confidently say it was a VAXFortran
extension except that the Sun files have it, too.  Given that, the
PRM_PAR files are actually less different from each other than they
might appear, so that they're precarious rather than terribly
non-standard.

Secondly, what is the idea behind the bad values, and how magic are
the particular values?  Are they just a sort of non-IEEE-specific NaN?
Or are they a specific flag value that would possibly find its way into
files (in which case the actual values couldn't ever be changed)?

I don't think they can be specific values, because the header of
PRM_PAR says ``This file defines machine-dependent public constants
for the PRIMDAT system'', and they _are_ machine-dependent, because
the various PRM_PAR source files define the _same_ bit patterns on both
big- and little-endian machines.  Unless, that is (and this is the link
with the first question), the 'hex'X notation has its value ordered in
significance order rather than memory order.

And what's with those bit patterns?  Given that that FF7FFFFF is just
an integer (that is, it's in significance order rather than memory
order, which makes sense), then it corresponds to the most negative
finite IEEE float, and that means that VAL__BADR is equal to NUM__MINR,
which is slightly surprising.  But then this is clearly not a special
number on a VAX -- and possibly not even a legal float, I can't remember.
So this can't be a platform-independent bad value that would ever find its
way into a file, and it's just a flag value that's possibly returned by
certain VAL_* functions, and it doesn't matter that there's a theoretical
chance that a bad value would be the correct result of a calculation.

This does seem to match how they're explained in SUN/39.

It would also be sensible, I think, to take the minimum and maximum
values from something like float.h, and just set the VAL__BADR and
NUm__MINR values, for example, to be the same as float.h's FLT_MIN.

Thus, yes, I'll make a new prm.h file primary, and effectively generate
PRM_PAR from that.

All this will be wrong on a 64-bit machine, of course....  Ah no, it
wouldn't be, not if it's taken from float.h!  So that's a Good Thing.
I think.

Also, I think that PRM_PAR doesn't have to worry about whether it's on
a big- or little-endian machine.  Which is also Good.

Right: that's probably a bit clearer to me (thanks for listening).
Any words of wisdom to add to that, anyone?

See you,

Norman


--
---------------------------------------------------------------------------
Norman Gray                        http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK     [log in to unmask]