Numerics, NaNs, IEEE 754 and C99

[rainbow.cougar at gmail.com]

Nick Maclaren wrote:
> ...
> Now, I should like to improve this, but there are two problems.  The
> first is political, and is whether it would be acceptable in Python to
> restore the semantics that were standard up until about 1980 in the
> numerical programming area.  I.e. one where anything that is numerically
> undefined or at a singularity which can deliver more than one value is
> an error state (e.g. raises an an exception or returns a NaN).  This
> is heresy in the C99 and Java camps, and is none too acceptable in the
> IEEE 754R one.
>
>...

As one of the few people on this group who will admit to programming
before  1980, let alone doing numerical programming then (I presume
writing code to process gigabytes of seismic data via Fast Fourier
equations meet your criteria), the only semantics that existed then
were for the program to *CRASH* hard when a singularity or undefined
state occurred. When using the various flavors of FORTRAN and vector
processors the undefined states could take a few microseconds to
manifest, but crash and burn they would, with some difficulty to
analyze the burning wreckage.

C is not a mathematically based language as FORTRAN is, so it is funny
to criticize it for being what it never was, however IEEE754 and NaN's
and the other standardizations put into place make back analyzing what
is wrong with your program and/or data far easier then what we had
before.


Curtis