Numerics, NaNs, IEEE 754 and C99

[Nick Maclaren]

In article <1150379424.085598.4130 at u72g2000cwu.googlegroups.com>,
"rainbow.cougar at gmail.com" <rainbow.cougar at gmail.com> writes:
|> 
|> 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.

Yes, it does, but I had used some dozens of systems, Fortrans and other
languages by then.  I did not make myself entirely clear, which partly
accounts for your response, but I am afraid that you are mistaken.

What I was referring to was that the consensus was that it was a
program error to calculate a value at a singularity or otherwise when
the result was mathematically undefined.

Yes, the languages specified that to be undefined behaviour (and usually
still do), but it was clear that a good implementation was ALOLOWED to
trap and diagnose the failures.  Many did and some still do - Python is
pretty good, but not in this area.

Examples of numerically near-bulletproof compilers included Egtran, XFAT
(if I recall after 35+ years), WATFIV, Delft Algol, SPITBOL, FLACC and
many others (and some in the 1980s, too).  MOST of the better Fortran
run-time systems (even IBM's Mod II library) used to detect and flag
invalid arguments to library routines.

==>>  Why should Python regard that, provably achievable, level of
      robustness as positevely undesirable?

|> 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.

As someone who has done it more-or-less continually since the 1960s,
I am afraid that is not so.  Yes, NaNs COULD do that, if the (fixable)
flaws in IEEE 754 were sorted out, but Java and C99 have picked up on the
flaws and used them as justification for ignoring 90% of the principles
of IEEE 754.

==>>  But the flaws in those are not the point here.  I am asking
      whether people would positively OBJECT (as the did in C99) to
      errors being detected, possibly as an overridable option.


Regards,
Nick Maclaren.