Optimizing IEEE Floating-Point Operations

eggert@twinsun.com (Paul Eggert)
Fri, 14 Jun 91 10:28:49 PDT

          From comp.compilers

Related articles
Optimizing IEEE Floating-Point Operations daryl@hpclopt.cup.hp.com (1991-06-06)
Re: Optimizing IEEE Floating-Point Operations bron@sgi.com (1991-06-11)
Optimizing IEEE Floating-Point Operations bill@hcx2.SSD.CSD.HARRIS.COM (1991-06-14)
Optimizing IEEE Floating-Point Operations eggert@twinsun.com (1991-06-14)
Optimizing IEEE Floating-Point Operations cfarnum@valhalla.cs.wright.edu (1991-06-17)
Re: Optimizing IEEE Floating-Point Operations henry@zoo.toronto.edu (1991-06-17)
Re: Optimizing IEEE Floating-Point Operations bill@hcx2.ssd.csd.harris.com (1991-06-18)
Re: Optimizing IEEE Floating-Point Operations jbc@hpcupt3.cup.hp.com (1991-06-19)
| List of all articles for this month |

Newsgroups: comp.compilers
From: eggert@twinsun.com (Paul Eggert)
Keywords: arithmetic, design, Fortran, C
Organization: Compilers Central
References: 91-06-005
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
these battles.

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!

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.