[Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #115 - 4 msgs

tbreuel at parc.xerox.com tbreuel at parc.xerox.com
Fri Oct 13 12:59:30 CDT 2000


On Fri, 13 Oct 2000 numpy-discussion-request at lists.sourceforge.net wrote:
> having Python you indeed have bad *and* incomplete 754 support on every 754
> platform it runs on.

Well, it depends on what you mean by "bad *and* incomplete 754 support".
IEEE recommends specific semantics for comparison operators in
language bindings, but I think their recommendations are undesirable
from a programming language and software engineering point of view.

If you follow IEEE semantics, you prohibit optimizers from optimizing
in many cases and it contradicts type system semantics in some
languages.  Worst of all, programs that rely on IEEE semantics
(in particular, of comparison operators) give no lexical indication
that they do so; they will simply do something wrong, like go
into an infinite loop or terminate a loop prematurely.

I think it's best to raise an exception for any expression involving
a NaN, unless the programmer explicitly indicated that he wants a
NaN result and IEEE semantics.

Another good approach is to provide separate IEEE operators and
leave the behavior of the built-in operators on IEEE special
values explicitly undefined.  This keeps people from relying on
one behavior or the other.

To me, the worst possible choice is to "implement IEEE semantics
correctly", i.e., in the way the IEEE authors envisioned it.
(Of course, IEEE is reasonably nice from a numerical point of view;
I just think they overextended themselves when talking about
language bindings).

> (*) Quiz:  *if* you can manage to trick Python into creating a NaN on your
> particular 754 platform, does the Python expression NaN == 1.0 return true,
> false, or raise an exception?  Answer before you try it.  Then try it on
> enough 754 platforms until you give up trying to guess in advance.  NaN ==
> NaN is predictable in Python, and is the one 754 feature Python guarantees
> won't work correctly on any 754 platform (although I've heard that it loses
> this predictability when run using NumPy's flavor of comparisons instead of
> core Python's).

This is just the sort of issue I was referring to.  In many dynamic
languages, the assumption is that pointer quality implies object
equality.  That's a perfectly reasonable semantic choice.  While
Python may not implement "754 correctly" in the sense of the (probably)
Fortran-thinking IEEE floating point designers, I think Python's
choice is correct and should not be altered.  People who really
want IEEE floating point comparison operations can use something 
like ieee.equal(a,b).  That alerts the reader that something special
is going on, it will fail on non-IEEE platforms (indicating that
the code wouldn't work correctly there anyway), and it makes
only the code that needs to pay the price for strict IEEE conformance.

Cheers,
Thomas.





More information about the Numpy-discussion mailing list