Numerics, NaNs, IEEE 754 and C99

[Grant Edwards]

On 2006-06-14, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
>
> The numerical robustness of Python is very poor - this is not its fault,
> but that of IEEE 754 and (even more) C99.  In particular, erroneous
> numerical operations often create apparently valid numbers, and the
> NaN state can be lost without an exception being raised.  For example,
> try int(float("nan")).
>
> Don't even ASK about complex, unless you know FAR more about numerical
> programming than 99.99% of programmers :-(
>
> 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).

That's fine as long as the behavior is selectable.  I almost
always want a quiet NaN.

While you're at it, the pickle modules need to be fixed so they
support NaN and Inf. ;)

-- 
Grant Edwards                   grante             Yow!  Yow!
                                  at               
                               visi.com