Some Q&A with Kahan on IEEE 754

[Huaiyu Zhu]

In comp.lang.python, you wrote:
>
>Note that I/O is a problem:  different platforms spell Inf and NaN in
>different ways, and Python currently defers to the platform atod and strtod
>to do string->float input.  Similarly for output.  I expect everyone will
>eventually move to the C99 spellings for these things, but before then
>Python may need to write its own (and just porting David Gay's routines for
>754 I/O to all the platforms Python uses could consume a good chunk of a
>release cycle ...).

I'm not sure if this is what you mean, but as a temperary measure wouldn't
it be feasible to let each platform emit its own spelling but capable of
accept any other would?  For example, in MatPy one can get NaN and nan but
both names refer to the same float object.  The challenge would be to deal
with MS spelling which is not a name, though.

>Note that comparisons are a problem.  754 implicitly defines 32 distinct
>binary comparison predicates (16 for which subset of {lt, eq, gt, unordered}
>is of interest, times 2 for whether or not a quiet NaN signals invalid
>operation).  But there's no way Python will grow new language syntax for
>these.  So this needs to be funneled thru a vanilla function interface.
>Also doubtful that
>
>    x == x
>
>will be changed to special-case NaNs; this currently returns 1 no matter
>what x is bound to because the same ("x is x") objects are being compared,
>and object identity is fundamental in Python.

Maybe this can be left with "rich comparison issues"?  I wrote to David
about the empty PEP but didn't get a reply, though.

>> ...
>> I think the problem here is in the definition of "Enable IEEE".  Your
>> meaning seems to be "Enable IEEE" == "Enable all/some IEEE 754 traps". My
>> meaning, and I believe the standard one is "use features available in
>> conforming IEEE 754 implementations." This is, by necessity, a superset of
>> the generic C floating point support (with a few notable, but minor
>> exceptions).

In these particular questions, my meaning of "enabling IEEE" is simply
passing through the the low level values (NaN, Inf) and the program flow.
Anyway, what Kevin is doing is much better than I had hoped for.

>Actually, all Huaiyu has been talking about is whether libm functions return
>Infs and NaNs.  Strictly speaking, that's not a 754 issue at all, as sqrt is
>the only libm function 754 mentions.  I know what he means, though, so
>haven't picked on that point <wink>.  He just never wants to see an
>exception raised by any fp operation.  That's a legit thing to want, but
>also a minority thing to want.  But getting libm to work predictably across
>platforms is a whole other can of worms, above and beyond 754 support.

Well, I was not concerned with what libm returns - they already return what
I want, correctly.  I was concerned about some auxiliary flags they set,
like errno, while not stopping a C program, will cause my Python program to
stop. This happens even when I know that returning NaN and Inf is correct in
these programs, and there being no way to avoid this extra checking in a
program.

Tim, I really appreciate your fine ability to make my words sound more
extreme then they were intended.  I'm getting used to it by now.  :-)

I do want raised exceptions if available.  That would be extremely handy in
some occasions.  But when faced with the choice of either always raising
overflow exceptions or never raising overflow exceptions, I find the latter
several times more preferable.  You did not put the question this way; if
you did you might find my view not a minority.  But since the 2.1 schedule
is so close and Kevin is working hard to make it into 2.1 this question is
moot.  Several months is a short time to wait.

>there's-several-person-years-of-work-here-ly y'rs  - tim

For 95% of support on 95% of platforms this may not be so costly.  And doing
so will likely make the remaining 5% an easier job, not harder, IMO.

but-never-say-never-ly y'rs

Huaiyu