Numerics, NaNs, IEEE 754 and C99

Nick Maclaren nmm1 at cus.cam.ac.uk
Thu Jun 15 10:16:47 EDT 2006


In article <1292p7s46ef5off at corp.supernews.com>,
Grant Edwards <grante at visi.com> writes:
|> On 2006-06-15, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
|> 
|> > Hence, the SAFE approach is to make the inverse of all zeros a
|> > NaN.
|> 
|> OK.  You're right.  I'm wrong about what my Python programs
|> should do.
|> 
|> In any case, that ship sailed.  

And sank, spawning a zillion lifeboats heading in different directions :-)

|> Maybe you can argue convincingly that theoretically your
|> approach is better than IEEE 754.  You're not going to get the
|> standard changed.  You're not going to get all of the computers
|> on the planet re-worked.  Making Python incompatible with IEEE
|> 754 is a bad idea.

No, that is wrong, on many counts.

Firstly, a FAR more common assumption is that integers wrap in twos'
complement - Python does not do that.

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).

Thirdly, virtually no hardware sticks strictly to IEEE 754, and no
language that I know of has EVER attempted to make it the strict basis
for its arithmetic model.

Fourthly, I am not proposing to change any hardware, and could even
provide a Python option to deliver mathematically incorrect results
when you want them.


Regards,
Nick Maclaren.



More information about the Python-list mailing list