Numerics, NaNs, IEEE 754 and C99

Grant Edwards grante at visi.com
Wed Jun 14 11:25:08 EDT 2006


On 2006-06-14, Nick Maclaren <nmm1 at cus.cam.ac.uk> 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).
>|> 
>|> 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).

The division by zero trap is really annoying.  In my world the
right thing to do is to return Inf.

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

-- 
Grant Edwards                   grante             Yow!  Were these parsnips
                                  at               CORRECTLY MARINATED in
                               visi.com            TACO SAUCE?



More information about the Python-list mailing list