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 -- http://mail.python.org/mailman/listinfo/python-list
