Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!cwi.nl!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <3652@charon.cwi.nl>
Date: 8 Jun 91 00:48:27 GMT
References: <9106052113.AA14439@ucbvax.Berkeley.EDU>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 70

In article <9106052113.AA14439@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
 >          I said:
 > >          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.
I still have a question here: do you know realistic cases where inferior
code will be generated?  I do not think that 'a = 0.0 * b' is realistic.

 >          Jim Dehnert said:
 >                                          and Inf really represents a
 > very large number
Or true infinite!
 >                     If I see a literal zero while compiling (the only
 > case I can think of when the compiler does anything that might care
 > about what 0*x equals), I feel quite free to assume that it is really
 > zero, in which case 0*x is really zero even for very large x.  So I
 > will do the same thing I would have for non-IEEE.  (This is the only
 > case I'm aware of where IEEE defines 0*x != x.)
In that case your compiler is not IEEE conformant.  To set it to 0.0 even for
literal zero is wrong because the infinity might have come from a division
by zero (and in that case it is a true infinity).
 > 
(about rounding modes:)
 >          This appears to apply just to convert to integer instructions.
 > Different modes could be offered for these instructions alone.  In any
 > case I don't believe they are useful for transcendental function algor-
 > ithms.  In fact the different rounding modes are a problem because the
 > functions must work for all modes.
I agree that floor and ceiling are not the reasons for the different rounding
modes.  The reason is simply interval arithmetic.  How would you get
reasonable performance with interval arithmetic if only one rounding mode
is available?  (See the papers from Kulisch et. at. from Karlstuhe University
where they do not only require multiple rounding modes but also an inner
product with only a single rounding to provide algorithms that give results
with proven error bounds that are very small.  Standard numerical analysis
only provides error bounds that are extremely pessimistic estimates in most
cases.)
 > 
(About trapping overflow.)
 >          Possibly I should be blaming Unix.  I tend to associate the
 > two.
(Associating Unix and IEEE arithmetic.)
An interesting remark when we know that the first IEEE conformant
implementation was the 8087 (not completely, conforming to a draft).
I would not associate the 8087 with Unix; other operating systems come
to the mind.  You should however not blame Unix (or any OS), you should
blame the compiler (and its run-time system).  Unix does not know anything
about IEEE because it also runs on quite a few non-IEEE machines (PDP-11).  The
compiler ought to provide (through library functions) access to the quirks
of IEEE.

 > >          79 bits is clearly an absurd length for a floating point
 > >format (the same is true of the 43 bit single extended format).
I am interested how you arrive at 79 bits.  I count 80: sign (1 bit),
exponent (15 bits) and mantissa (64 bits) for double extended.  Note:
there is no implicit bit in the standard extended formats!

 >          Herman Rubin asked:
 > Why should it even be the case that the exponent and significand are in
 > the same word?
 > 
 >          Because if they aren't every load or store will require 2 mem-
 > ory references instead of 1 halving the speed in many cases.
Oh well, von Neumann advocated the use of scaled fixed point numbers.  He
did not even consider floating point hardware.  But I agree here, when we
have fp hardware it makes sense to have exponent and mantissa in the same
unit of information.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl