Some Q&A with Kahan on IEEE 754

[Edward Jason Riedy]

And Tim Peters writes:
 - 
 - >   5) Thread specific handling of traps with creation-time inheritance of
 - >      settings.
 - 
 - Yes, all 754 state (rounding, precision, sticky flags, trap masks) must be
 - part of thread state.

The fun part is in the implementation, which is what I was pondering
before (in case you meant me).  I've never checked to see if threads
behave sensibly in this respect on various platforms.  Considering
how different vendors implement compiler parallelization, I wouldn't
be at all surprised if there are significant differences between
platforms.

 - Less clear is whether sticky flags should be inherited too or 
 - cleared in a new thread; I favor the latter [...]

Even given a single method call that clears the flags and makes the
intent equally clear?  I suspect that some OSes keep the sticky
flags (fork-join type semantics), some clear them (for your reasons),
and others give you random crap (poor implementation of threads from 
a thread pool).

 - Signaling NaNs are a minor feature; I'm not sure I've *ever* seen 
 - them used (on purpose <wink>).

Remember that every NaN read from I/O is supposed to be a signalling
NaN.  It's one of those really disgusting parts of 754 that can be 
dropped without complaint (I hope).

 - >   2) Speaking of signal handlers, Tim Peters stated that returns are not
 - >      allowed from sIGFPE handlers.  I have yet to see this restriction in
 - >      any platform documentation.  What is the deal?
 - 
 - C standard.

Also the Single Unix Specification's definition of sigaction:
>  * The behaviour of a process is undefined after it returns normally 
>    from a signal-catching function for a  SIGBUS, SIGFPE, SIGILL or
>    SIGSEGV signal that was not generated by kill(), sigqueue() or 
>    raise(). 

 - For example, if you try to return from a SIGFPE handler on a WinTel box, 
 - you *usually* get into an infinite loop, [...]

Same on Intel/Linux.  Sparc/Solaris seems to return normally, 
and is backed up by the example in their documentation for 
ieee_handler.

 - Note that I/O is a problem:  different platforms spell Inf and NaN in
 - different ways, [...].  I expect everyone will eventually move to the 
 - C99 spellings for these things, [...]

Does that coincide with the XML Schema spellings (INF and NaN)?
Or Java's (Infinity and NaN)?  Those are two non-trivial groups
that might want it their way.  As long as it's well defined for
Python, though, it's no big deal.

[On the insane number of comparators...]
 - But there's no way Python will grow new language syntax for these.

The current ones plus the ability to test the invalid flag is
all that's really necessary.  Further comparators are nice for
compilers that are told not to optimize anything.

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

That is why there's is.  The statement "x is NaN" or "x is x" where 
x holds a NaN should be true, but I would request that NaNs be 
special-cased in == by the principal of least surprise when migrating 
from other languages.  And saying == has something to do with object 
identity gives it two different meanings in different situations.

My mental model for working with these things is that there's only
one number 1.0, one +Inf, one NaN, and that variables just reference
those things.  Then something like "is" checks to which objects things
are bound, and something like "==" actually interrogates the objects,
possibly with object-specific semantics.

Also, consider a case where you're comparing terms in two sequences
to see where they diverge:
  while x == y:
    x = A.next_term()
    y = B.next_term()
Particular choices may give one sequence suddenly diverging to 
Inf - Inf and another diverging to sqrt(-1).  Personally, I think 
it would be sensible (minimally surprising?) to stop the iteration 
there...  But then this is a pretty lousy example.



BTW, there's another issue with trapping:  When a complex operation
traps, should we expose the individual floating-point operation that
trapped underneath it?  (Assuming Python keeps its own implementation
rather than relying on (broken) compilers' complex types.)  Personally,
I think not.

[Also, Dr. Kahan's down on trapping simply because they're such a bear
to implement.  I've gotten the feeling that he'd find an easy to use
trap system interesting.]

Jason