🚀 go-pugleaf

         I said:
>        I checked the Goldberg reference.  He states in effect the pur-
>pose of his paper is to explain IEEE floating point not defend it.
         Henry Spencer said:
Did you read the paper, or just the introduction?  He does a fairly good
job of justifying the various decisions as he goes.

         I have looked through the paper ("What Every Computer Scientist
Should Know About Floating-Point Arithmetic" by D. Goldberg, ACM Compu-
ing Surveys, Vol 23, 1991, p5-48).  He provides examples of ways in which
various features of IEEE arithmetic can be used.  I don't consider the
fact that a feature has some use justification for including it.  Justif-
ication would also consider the cost of providing a feature and discus-
sion of alternative ways of providing some or all of the benefits.  A
feature should be included only if this sort of analysis indicates a
favorable cost/benefit ratio.  The paper does little of this and indeed
the author states this is not the purpose of his paper.
         Additionally some of the examples of how to use IEEE seem ill-
advised to me.  I will discuss one example.  On page 22 the author says
(I have made small changes to the notation, fmax is the largest finite
floating point number):

>Here is a practical example that makes use of infinity arithmetic.  Con-
>sider computing the function x/(x**2+1).  This is a bad formula, because
>not only will it overflow when x is larger than <sqrt(fmax)>, but infin-
>ity arithmetic will give the wrong answer because it will yield 0 rather
>than a number near 1/x.  However x/(x**2+1) can be rewritten as 1/(x+
>1/x).  This improved expression will not overflow prematurely and be-
>cause of infinity arithmetic will have the correct value when x=0: 1/(0+
>1/0)=1/(0+inf)=1/inf=0.  Without infinity arithmetic the expression 1/
>(x+1/x) requires a test for x=0, which not only adds extra instructions
>but may also disrupt a pipeline.  This example illustrates a general
>fact; namely, that infinity arithmetic often avoids the need for special
>case checking; however formulas need to be carefully inspected to make
>sure they do not have spurious behavior...

         I have the following comments.
         1)  If the user uses the original "bad" formula out of careless-
ness or a belief x will never be large then as the author notes IEEE
arithmetic may compute a totally bogus result with no error indication
(other than the setting of an overflow bit which nobody looks at).  On
other systems the error is usually more obvious.
         2)  An alternative way of dealing with the large x problem is:
      if(abs(x).le.1.0d18)then
        y=x/(1+x*x)
      else
        y=1/x
      endif
Compared to the author's solution, this has the following virtues
         a)  It is more portable.
         b)  It will be faster (at least on scalar machines) because it
uses a single floating point divide.
         c)  It will work properly on denormalized inputs.  The authors
code fails whenever 1/x overflows but x is not 0.  Note the original
"bad" code handles this properly.
         3)  Coding intentional harmless overflows makes it very diffi-
cult to detect unintentional harmful overflows (such as the original
formula can produce).  Thus coding in the author's suggested style would
appear to be dangerous.
         To sum up, in my opinion all that this example shows is that
infs provide a new way to screw up.
         Another quote from this paper.  In a footnote on page 17 the
author states:

>According to Kahan, extended precision has 64 bits of significand be-
>cause that was the widest precision across which carry propagation
>could be done on the Intel 8087 without increasing the cycle time...

         This may constitute justification to 8087 designers, I don't
see why it should be for the rest of us.

                       James B. Shearer