Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!ucbvax!watson.ibm.com!jbs
From: jbs@watson.ibm.com
Newsgroups: comp.arch
Subject: IEEE arithmetic
Message-ID: <9106032144.AA15477@ucbvax.Berkeley.EDU>
Date: 3 Jun 91 21:47:19 GMT
Article-I.D.: ucbvax.9106032144.AA15477
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 45


          Several people have challenged my characterization of typical
behavior on fp overflow in pre-IEEE environments.  In my defense I was
not intending to claim the exact behavior of IBM fortran was typical,
just the fact that x/(x*x+1) cannot silently produce garbage.  Even so
it appears that pre-IEEE behavior was more diverse than I had realized.
          I said:
>... The rationale behind the extended formats:
>providing extra precision for intermediate terms is ridiculous.  If the
>added precision is available it should always be used otherwise it is
>of little value...
          Henry Spencer says:
Having had some need to compute hypotenuses without overflow in code that
otherwise wanted to use single precision for speed, I'm afraid I disagree.
Whether it is "of little value" depends a lot on what you are doing.

          First a nitpick, you are using the extra exponent range not
extra precision.  In deciding whether a feature is of value one must
look at alternatives.  In your example the obvious alternative is to
compute the hypotenuses using double precision.  I do not see any reason
for an intermediate precision.  Btw how exactly would you expose an
intermediate format to the user?
          Dik Winter said (responding to the same statement):
Providing extra precision for intermediate terms is *not* ridiculous.
Witness the maf instructions on the RS6000.  Witness also the many old
papers that use inner products calculated in extra precision.
The problems with hex format are the following:
1.      The wobbling precision must let you use the worst case for error
        estimates.
2.      This makes single precision much more useles than binary single
        precision is already.
Note also that Blaauw reportedly has said that were he to design FP again
he would not use hex.

          I believe the maf instructions omit the intermediate round-
ing step primarily to improve performance.  I believe the papers to
which you refer basically require a way to obtain the double precis-
ion product of two single precision numbers.  I consider this a some-
what different issue.
          I agree that binary formats are superior to hex in that they
provide 2 extra bits of precision.  I don't agree (particually for 64-bit
formats) that this 2 bits makes it significantly easier to avoid numer-
ical problems.  If I were to design a FP format I would probably use
binary also.  I am not objecting to the use of binary.
                           James B. Shearer