Some Q&A with Kahan on IEEE 754

[Huaiyu Zhu]

In the past few days I asked Prof Kahan several questions about IEEE 754.
He kindly replied to my questions promptly (but he warns he's falling behind
40 of 100 emails a day, so I'm unlikely to ask him again).  He gave
permission to forward his comments here.  My questions are included here to
provide context.  (And to reveal my ignorance. ;-))

Huaiyu

[Huaiyu Zhu]
> ...  As I understand, the intention of IEEE 754 is for
> every exception to raise a flag, so that the programmer can choose to deal
> with it, or not.  This is considered a good thing compared with aborting the
> computation unless an error is trapped.

[W. Kahan]
   The intention is ...
   0)  Ensure that a program's behavior is predictable without stopping it and 
       losing control.
       
   1)  Allow programmers to deal with exceptions where most appropriate for 
       their programs,  sometimes ...
        a)  Testing operands in advance to prevent exceptions
        b)  Testing results immediately after an operation to detect exceptions
        c)  Testing flags some time afterwards to catch previous exceptions.
       The ability to postpone judgment is as important for programs as for
       anything else in life.
       
    2)  Allow programmers to ignore exceptions with a predictable risk,  made 
        as small as we can by apt choice of default values,  of subsequent 
        malfunction.

[Multiple choices]
> Python is a scripting language that is available on a variety of platforms,
> not all of which support IEEE 754.  On IEEE-enabled platforms there are
> choices of whether to enable it, and what to do with the exceptions.  I
> would like to hear your opinion on the following choices:
> 
> 1. Enable IEEE whenever possible.  Let all f.p. exception go through without
>    any action.  The user could test for NaN and Inf afterwards.

     NO!  This is what  Java  does,  and it is a serious mistake.

>
> 2. Enable IEEE whenever possible.  Each f.p. exception produces a Python
>    exception, which would halt the program unless trapped and handled.

     This is an option worth integrating with a debugger,  but it must not 
     be the default.  Do you really wish to see  Python  programmers trying
     to program their own trap handlers?  The expreience with  PL-1  and 
     BASIC  trap handlers is ominous;  they enlarge enormously the capture-
     cross section for mistakes.

>
> 3. Enable IEEE whenever possible.  Let underflow go through, but let each
>    overflow generate a Python exception.

     NO!  The programmer is the only one competent to decide which exceptions
     his program can ignore,  which to allow to pass on to detection later, 
     which to trap if they must.

> 
> 4. Enable IEEE whenever possible.  Let a special module contain all the
>    flags, without changing program flow.  Programers could choose to examine
>    these flags or choose to ignore them.

     Yes; and provide quick and convenient ways to save-and-restore and
     merge exception flags.  Other facilities should be provided too, but I
     cannot spare the time just now to discuss them in detail.
     
     An example worth study is the exception-handling provided by Apples old
     SANE for the 680x0-based Macintoshes.  It was published about a decade
     ago by Addison-Wesley.

> 
> 5. Do not enable IEEE until there is universal support, or at least until it
>    can be faked on those other platforms.

     Upon what hardware that does not support IEEE 754 do you expect Python
     to run?  There is substantial support for IEEE 754 in C-9X compilers
     too; and Borland's C for the Pentiums provides some too.  Of course,
     you have to provide Software flags (declared variables) for exceptions
     rather than give programmers direct access to the hardware flags and
     control register.

[Huaiyu Zhu]
> The current problem with IEEE 754 support in Python is that, at least as it
> is perceived, there is no general way to turn it on on every 754-enabled
> platform and expect to obtain the same kind of signalling, etc.

[W. Kahan]
  I don't understand why you cannot package the interface to the  IEEE 754 
  flags and implement this relatively small package as required  (different 
  for different compilers/hardware platforms)  with your distribution of 
  Python.  Of course,  the work involved in producing the first package or 
  two will be appreciable;  but it gets easier after that  PROVIDED  you 
  choose compilers that have the necessary hooks.

[Huaiyu Zhu]
> Another
> problem is that the leading authorities of the language plan to unify the
> behavior in such a way as to raise exceptions for Overflow, Divide-by-Zero,
> Invalid Operation, while letting through Underflow and Inexact Operations.
> They consider this as an interim step toward full IEEE 754 support. 
> Since Python exceptions have to be caught, this would make life extremely
> difficult for vectorized computations during this period.

[W. Kahan]
  "Interim steps"  have a tendency to become permanent in our industry,  where
  "Compatibility"  is the way the sins of the fathers are inflicted upon the 
  third and fourth generations ... .                                    W. K.