[Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

[Mark Favas]

[Huaiyu Zhu, replying to Tim...]
>It is interesting to know that someone actually relies on >OverflowError to detect underflow.  But why not let them continue that >as well, given that all of these would be available in the future >anyway?

I think I'm the someone referred to - but I _don't_ rely on this at all.
I was reporting that, on my platforms, the behaviour of exp(-666) did
_not_ change between 1.5.2 and 2.0, both of which raised an
OverflowError (for underflow). I prefer Tim's change so that exp(-huge)
will produce 0, and that exp(huge) produces an OverflowError, even
though this changes the behaviour when moving from 1.5.2 to 2.x...

[Huaiyu Zhu again]
>Before that happens, why consistency accross platform is deemed more
>important than consistency accross releases?  My naive thinking is >that people port more from 1.5.2 to 2.0 than from one platform to >another, isn't it?  :-)

In spite of the smiley, I'd have to say (politely) "Rubbish!". One of
the many attractions of Python to me _is_ cross-platform consistency -
more so than up-version consistency. In my previous life as a
computational chemist I spent a lot of effort in writing code that was
portable - indeed, we developed a pre-processor language (which spat out
FORTRAN) to try to more easily handle
OS/compiler/word-size/FP-characteristic/phase-of-moon issues. I first
came up against IEEE stuff in the early 80's, and I agree with Tim - as
a user, I hated the non-stop defaults. Mollycoddled by CDC machines, I
was used to my code stopping when I divided by zero - it usually
indicated a coding or algorithmic error. When (if) Python supports
access to masking/unmasking 754 exceptions, that'll be good - in the
meantime, from my POV, the steps taken by Tim/Guido are in the right
direction.

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA