24 May
2007
24 May
'07
10:42 a.m.
On Wed, May 23, 2007 at 11:54:21PM +0200, Fons Adriaensen wrote:
1. There is absolutely no ambiguity in order of execution of the statement
above.
- subtract a from x
- multiply by b
- add 0.5
- cast to int
2. In both cases the floating point result was the same. Only the case to int
was different.
My guess is that you're running into an issue with floating-point
representations that differ by some value near to machine epsilson.
In these cases, results can get very unpredictable and either
1) Don't do that, or 2) If you must, use a wider floating point
representation. This especially hits in the case of loops because
you may be seeing the effects of accumulated error: 10^(-10) is very
small, but if you accumulate enough of them, they really can affect
your results, potentially enough to change the value of a cast.
Along those lines - is it possible that with -march=pentium4 that gcc
is generating 64- or 128-bit floats? This might be happening if it's
vectorizing your loop via SSE. Paul's -S diff s probably the way to
check this.
Could you provide sample values for a, b, and x along with the results
you are seeing? A source code snippet to compare with would be even
more fun ::-).
--
Ross Vandegrift
ross(a)kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
This is with -O3. Same with -O2, -O1, but OK without
optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
It might not be a bug. You are not guaranteed of the same order of
evaluation of arithmetic expressions in C. If you want that you have
to use FORTRAN or assembler (maybe some other language has it also).