|Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-06)|
|Re: Optimizing IEEE Floating-Point Operations email@example.com (1991-06-11)|
|Optimizing IEEE Floating-Point Operations bill@hcx2.SSD.CSD.HARRIS.COM (1991-06-14)|
|Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-14)|
|Optimizing IEEE Floating-Point Operations email@example.com (1991-06-17)|
|Re: Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-17)|
|Re: Optimizing IEEE Floating-Point Operations email@example.com (1991-06-18)|
|Re: Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-19)|
|From:||email@example.com (Paul Eggert)|
|Keywords:||arithmetic, design, Fortran, C|
|Date:||Fri, 14 Jun 91 10:28:49 PDT|
[... the IEEE FP standard and the various language standards
talk past each other, leaving large grey areas. -John]
It's worse than that -- sometimes the standards flatly contradict each other.
E.g. IEEE 754 says that if you print -0 and read it back in again, you should
get -0, not 0; Fortran says that you can't tell the differences between
printing -0 and 0. Luckily these cases are few; in practice IEEE 754 loses
However, when IEEE 754 says ``the implementation must do A'' and a language
standard says ``the implementation is free to do either A or B'',
implementers desiring high performance sometimes improperly take the latter
statement as a license to do B while claiming support for IEEE arithmetic.
As a programmer, sometimes I prefer performance, but usually I prefer
standard, repeatable arithmetic. A good compromise is for implementers to
have a compiler option like `-fast-but-loose' that means ``don't bother to
obey IEEE 754 exactly, just make it run fast.'' Clearly optimizing 0.0*X to
X falls in the fast-but-loose category in an IEEE environment where X might
be a NaN. Some implementers might get by with supporting only the
fast-but-loose semantics, but if so I hope they don't pretend that they
conform to IEEE 754.
Unfortunately, new standards continue to be developed with equally large grey
areas. E.g. a proposed international standard called LCAS aims to provide a
language-independent standard for computer arithmetic, but it ignores all
issues of NaNs, Infinities, -0, etc.
In a more hopeful development, the NCEG group is considering a standard for
IEEE 754 support for Standard C. Let's hope they address the 0*X issue!
Return to the
Search the comp.compilers archives again.