Comments on LIA

[James Demmel]

Regarding Kahan's comments on the LIA, I would appreciate hearing exactly
how the LIA addresses some of his detailed technical criticisms published 
in the SIGNUM Newsletter, v. 26, n. 3 (1991) pp. 2-15. As I read the second 
LIA draft, I could not find them addressed.
   
I think his general criticism is that some useful programs and programming
techniques which work well now could not be written and shown correct 
given the information available from proposed LIA environmental enquiries,
or at least it is hard to tell how. 

     How would one write a program to compute (x+y)/2 portably in LIA?
        The 13 line program in draft 1 of LIA apparently had a bug, and the 
        shortest correct program Kahan could write (10 lines) was still
        much more complicated than the more or less obvious 4 lines that
        works in IEEE arithmetic (see pages 11-14 of the Kahan article for 
        details).  If writing something so simple as (x+y)/2 in a portable 
        way is hard even for the LIA designers, what about average 
        programmers writing complicated codes?

     Simulating double precision with single (or quadruple with double)
        is possible using techniques of Dekker, Linnainmaa, Priest and
        others provided the arithmetic is good enough. This makes some
        codes much easier to write since we can just use higher precision
        in a few places if necessary. Does LIA provide enough information
        to determine whether we can use these techniques or not? Different
        simulations with different complexities are possible on different
        arithmetics, with machines with fused multiply-add instructions
        like the RS6000 being significantly faster at this. Will the LIA
        permit writing the fastest code possible? The performance difference
        can be large.

     Sign symmetry like x-y=-(y-x) is a useful property to have. How can
        we know we have it when we want it, yet support the roundings
        needed for interval arithmetic, where it is false?

     General purpose zero-finding subroutines, which find a zero of
        a function f(x) given the ability to evaluate f, can only
        be generally reliable if the system can gracefully deal with
        x's which are outside the range of f. In IEEE systems, this is
        naturally signalled by f returning a NaN, which the zero-finder
        can detect and react accordingly. Why should the LIA not make
        it possible to write such a code when it is widely possible,
        and widely done on calculators?

     x/sqrt(x**2+y**2) never exeeds 1 in magnitue on IEEE, Vax, IBM 370 or 
        correctly rounded decimal arithmetic, eliminating the need to write
        expressions like arccos(max(-1.0,min(1.0,x/sqrt(x**2+y**2)))).
        The proof differs in all these arithmetics. The expression can
        exceed 1 on Crays. Does LIA provide enough information to draw
        any conclusions about this expression?

There are other questions raised in the article; these are a sample.
I look forward to a detailed technical response to these questions, as well
as my own.

   Jim Demmel