Numerics, NaNs, IEEE 754 and C99

[Nick Maclaren]

In article <12904mjhl493t49 at corp.supernews.com>,
Grant Edwards <grante at visi.com> writes:
|> >
|> > 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.

That is one of the two modes that I regard as respectable.  However,
because integer arithmetic doesn't have a NaN value (which could be
fixed, in Python), anything that returns an integer has to raise an
exception.  On that matter, division by zero and several other currently
trapped numeric errors could be modified to return NaN for people like
you (if the option were selected, of course).

I will take a look at adding NaN to integers, but that is a much
hairier hack - and it STILL doesn't deal with comparisons (which can
be done only in a purely functional programming language).

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

Yup.  On my list :-)


Regards,
Nick Maclaren.