Newsgroups: comp.arch
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: IEEE floating point (Goldberg paper)
Message-ID: <1991May31.203750.2523@zoo.toronto.edu>
Date: Fri, 31 May 1991 20:37:50 GMT
References: <9105310523.AA15861@ucbvax.Berkeley.EDU>
Organization: U of Toronto Zoology

In article <9105310523.AA15861@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>Justification 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...

My understanding is that the funnier-looking features, in particular the
infinities, NaNs, and signed zeros, mostly cost essentially nothing.
Getting the rounding right reportedly takes work, but that one seems easy
to support.  As far as I know, the *only* thing in IEEE arithmetic whose
cost/benefit ratio has been seriously disputed is denormalized numbers.

>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.

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.

>>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.

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.
-- 
"We're thinking about upgrading from    | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 to SunOS 3.5."              |  henry@zoo.toronto.edu  utzoo!henry