Re: Floating point constant question

Scott Mahlke <mahlke@crhc.uiuc.edu> writes:
|> I have a question regarding the following compiler optimization:
|> x = y / 500.0; ===> x = y * 0.002;
|> Is this or similar optimizations dealing with FP constants ever legal?


chase@Think.COM (David Chase) writes:
>I don't know of any compilers that do, and if they did them generally
>(i.e., if they'd do exactly what you did) then I wouldn't buy them. If
>your goal is to not change the I/O behavior of a legal program (something
>I always take for granted as a constraint on an optimizer), then my rule
>is that you cannot do this if the reciprocal cannot be represented
>exactly, in fact not even if the divisor cannot be represented exactly


This is a place where a competent standards committee could really help by
specifying under what conditions you can rely on certain levels of
accuracy for the representation of constants. So far as I know, only Ada
requires that arithmetic on _constants_ be _exact_. In other words, I
could express a constant computation such as computing the 100,000'th
decimal digit of pi, and so long as the Ada compiler didn't run out of
room, it would have to give me the correct answer in order to meet the
standard.


There are a pair of papers that every card-carrying reader of
comp.compilers must read and should be part of the FAQ:


Clinger, W.D. "How to Read Floating Point Numbers Accurately". ACM
Sigplan'90 Conf. on Progr. Language Design & Implementation, White
Plains, NY, June, 1990, 92-101.


Steele, G.L., and White, J.L. "How to Print Floating-Point Numbers
Accurately". ACM Sigplan'90 Conf. on Progr. Language Design &
Implementation, White Plains, NY, June, 1990, 112-126.


Conversions are a problem which is bound to only get worse. There is a
tendency for everyone -- compilers, networks, xdr's, etc., to convert FP
to decimal and let the guy at the other end deal with the loss of
precision. For example, what good is it for a compiler to read a constant
accurately, and provide an accurate representation for the assembler if
the assembler then goes and trashes the constant. Paranoid compilers I
have seen convert the constant into hex so that the assembler can't screw
it up. On the other hand, some assemblers -- particularly the IBM
assemblers of the early 1960's -- went to much more trouble to do accurate
conversions than did compilers of the time, so it would have been better
to pass through the decimal constant unchanged to such an assembler.


Due to the uncertainty created by bad standards in this area, the person
who has to do professional, portable code is forced to do some pretty
bizarre things to make sure that his program will work on every machine.
He also is forced to often accept performance hits for the same reason.


Unfortunately, otherwise excellent articles such as the one in Computing
Surveys -- "What Every Computer Scientist Should Know About Floating-Point
Arithmetic" by David Goldberg, seem to always neglect the problem of I/O
conversion. What's needed here, of course, is a hex standard for IEEE
float, so that heroic measures are not usually necessary to preserve
floating point numbers during transfers to other environments. Ada, for
example, does have the ability to specify numbers in a floating hex format
(and a floating binary format, as well, if you really want it).


C gives you the ability to do non-decimal floating point constants, but
it's not portable, because it gives you access to the actual
representation.
--

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