Numerics, NaNs, IEEE 754 and C99

[Nick Maclaren]

In article <4490315e$1 at nntp0.pdx.net>,
Scott David Daniels <scott.daniels at acm.org> writes:
|> Grant Edwards wrote:
|> 
|> > While you're at it, the pickle modules need to be fixed so they
|> > support NaN and Inf. ;)
|> 
|> The NaN problem is portability -- NaN values are not standard, and
|> pretending they are won't help.  There are many possible NaNs, several
|> of which have desirable behaviors, and different processors (and 
|> Floating Point settings) choose different bit representations for
|> those NaNs.  There are at least: Inf, -Inf, NaN, Ind (Indeterminant).

The main meaning of NaN is Indeterminate (i.e. it could be anything).
If you mean 'Missing', that is what was and is done in statistical
packages, and it follows very different rules.  There are several other
meanings of NaN, but let's not go there, here.  Though I have document
I could post if people are interested.

|> Being able to pickle some of these will produce values that "don't
|> behave right" on a different machine.  Up until now, I think you can
|> send a pickle of a data structure and unpickle it on a different
|> processor to get equivalent data.

No, it could be done right.  The unpickling would need to detect those
values and raise an exception.  You have to allow for it even on the
same 'systems' because one Python might have been compiled with hard
underflow and one with soft.   Your really DON'T want to import denorms
into programs that don't expect them.


Regards,
Nick Maclaren.