Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!WATSON.IBM.COM!jbs
From: jbs@WATSON.IBM.COM
Newsgroups: comp.arch
Subject: IEEE arithmetic (Goldberg paper)
Message-ID: <9106010224.AA28532@ucbvax.Berkeley.EDU>
Date: 1 Jun 91 00:47:30 GMT
Sender: rwh@ucbvax.BERKELEY.EDU
Lines: 76


          Henry Spencer says:
My understanding is that the funnier-looking features, in particular the
infinities, NaNs, and signed zeros, mostly cost essentially nothing.

          I believe this statement is incorrect.  Infs and nans compli-
cate the design of the floating point unit.  Even if there is ultimately
no performance impact, this added design effort represents a very real
cost.  Perhaps some hardware designers could comment.
          Also as has already been pointed out there is a software cost
due to such features as 0*x no longer being 0.  In some cases this will
have a performance impact in that compilers will generate inferior code.
          Henry Spencer says:
Getting the rounding right reportedly takes work, but that one seems easy
to support.

          As far as round to nearest goes, this does provide a real
benefit.  I am not totally convinced it's worth the cost but a case can
made.  The case for the round to even (when halfway) seems much more
dubious.  I believe this represents a substantial portion of the cost
(comments?) and the additional benefits seem quite tenuous.  I don't
see any good reason for the other 3 modes.
          I said:
>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.
          Henry Spencer said:
Only if the author goes to substantially more trouble than merely looking
at an overflow bit.  This really sounds to me like the old "people wrote
better when they had to retype a whole page to fix an error, because they
had to think about it more" fallacy.  People who took care before will
continue to take care; people who didn't before won't now.  The difference
is that both are somewhat less likely to get plausible-looking garbage now.
Nobody is proposing that IEEE arithmetic is a replacement for care and
understanding.  All it does is improve the odds that a given amount of
care and understanding will produce meaningful answers.

          I guess I was a bit obscure here.  On IBM hex systems when
floating overflow occurs the default behavior is for an error message
to be printed which includes a traceback pointing to the offending
instruction.  Execution then continues (with the max floating number as
a fixup) but will terminate if more than a small number (5?) of over-
flows occur.  I was under the impression that this was typical behavior
for pre-IEEE systems.  Is that not the case?
          I consider this behavior much friendlier than typical IEEE
behavior which is to run to completion then output infs and nans (or
worse plausible but wrong numbers) with no indication of where the
error occurred.
          It seems to me that the existence of infs in IEEE is in-
creasing the likelihood of obtaining plausible-looking garbage.
          I said quoting the paper:
>>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.
          Henry Spencer said:
To me it sounded like "the precise number of bits was not thought to be
crucial, so the limitations of a very important existing implementation
were taken into consideration".  If you don't like this, explain why the
resulting number of bits is wrong or inadequate.  If it's satisfactory,
why do you care how it was arrived at?  Standards decisions often turn
on such seemingly trivial or ephemeral issues; what matters is the
result.

          I was unaware the Intel 8087 could be considered a "very
important existing implementation" as compared to the DEC format for
example.  Do you have some evidence for this?
          79 bits is clearly an absurd length for a floating point
format (the same is true of the 43 bit single extended format).  As well
being very awkward the extended lengths are too close in precision to
the unextended lengths.  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 (see various comments on hex format).
                       James B. Shearer