Numerics, NaNs, IEEE 754 and C99

Grant Edwards grante at visi.com
Thu Jun 15 11:43:12 EDT 2006


On 2006-06-15, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:

>|>> Firstly, a FAR more common assumption is that integers wrap in twos'
>|>> complement - Python does not do that.
>|> 
>|> It used to, and I sure wish there was still a way to get that
>|> behavior back.  Now I have to do all sorts of bitwise ands that
>|> I didn't use to.
>
> Given that it is perhaps THE most common cause of severe
> failure in large scientific codes, I don't agree that it
> should be the default. A 'twos complement' class would be
> quite reasonable.

Since Python went to non-fixed-length integers, a couple of
those classes have been written.  I tried one of them and it
was rather clumsy.  There was no conversion/coercion between
different widths or between fixed-width integers and "regular"
integers.  That mean you had to call a constructor even if all
you wanted to do was add 2 to a value.

>|> > Secondly, it is NOT incompatible with IEEE 754, which is a
>|> > pure hardware standard.  All it does is to trap the exception
>|> > and take appropriate action (as permitted by that standard).
>|> 
>|> There are two allowed (selectable?) behaviors for 1/0: trap and
>|> Inf.
>
> Er, no.  The second is REQUIRED to set an exception flag,

But it's not required to generate a trap according to my
reading of the spec.

> which IEEE 754 assumes that the code will test and take
> appropriate action (which can be anything, including aborting
> the program and replacing it by a NaN). See
> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

  IEEE Std 754-1985, subclause 7.2 - Division by Zero

    "If the divisor is zero and the dividend is a finite nonzero
     number, then the division by zero shall be signaled. The
     result, when no trap occurs, shall be a correctly signed
     (infinity symbol)(6.3)."

To me it looks like the spec specifically allows for a case
where "no trap occurrs" and the result is Inf.

>|> As long as I can get IEEE 754 results, that's cool.  I'd prefer
>|> if Python just let the HW do it's thing when possible.
>
> Including crash and burn?

No. :)

> Seriously.  I don't think that you realise just how many
> layers of fixup there are on a typical "IEEE 754" system, and
> how many variations there are even for a single platform.

Probably not.

-- 
Grant Edwards                   grante             Yow!  My face is new, my
                                  at               license is expired, and I'm
                               visi.com            under a doctor's care!!!!



More information about the Python-list mailing list