What is acceptable for -ffast-math? (Was: associative law in combine)

[Theodore Papadopoulo]

gdr@codesourcery.com said:
> No, I do mean a transformation which does not dramatically transmute
> the computations.  

That's not a definition. Dramatically, can mean very different things 
depending on the people and on the algorithms. That's basically the 
point that I'm trying to make. In many applications and algorithm
the optimization a/b/c to a/(b*c) is meaningful and relevant. Not 
everyone will have floats that are 2*sqrt(DOUBLE_MAX) (or any other 
combination that might overflow). Actually, a lot of people use a 
representation to make computation that is much wider than the 
accuracy of the input and the accuracy you can get on the output.

Let's face it, there are two ways of using floats.

1) you take enough margin to not care about the accuracy problems (ie 
you take several bits more than ``needed''), and then want to write 
your program as naturally as possible and expect the compiler to do 
what is possible for the computation to be as fast as possible.

2) You are constrained either by the accuracy you would like to get 
or by the size of your data. Then you tend to write without these 
extra bits and pay much more attention to the rounding effects.

NONE OF THE MODELS IS BETTER THAN THE OTHER. There should be 
support in gcc for both communities. You can argue that wanting to 
speed up a computation made with doubles that could have been with 
simple floats is stupid, but:

a) double are often as fast or even faster than floats. Until fairly 
recently, a lot of processor were doing float computation by truncating
the results of a double computation. Recent Sparc processor indeed 
have hardware floats, that go faster than doubles but not 2 times 
IIRC.

b) Writing code that extracts every single possible bit of accuracy 
tends to be very difficult to understand and maintain (see eg DNRM2 
or FNRM2 in blas that just computes the Euclidean norm of a vector 
and you will understand what I mean. By the way, I'm sure that 
nowadays, implementing FNMR2 with double would be faster at the same 
accuracy and much simpler to maintain. For DNMR2 things are more 
compilcated as we would have to switch to long double with which I 
have little experience).


The fact that "95% of the folks out there are completely clueless about
floating point. (J.G. 28 Feb. 1998)" have to be taken into account.
For at least quite many of those 95%, floating point works because 
they are not experiencing the "bounds" of floting point and merely 
stay in the safe area provided by the extra bits of accuracy.

By the way the previous sentence is  cited in a report of Kahan and Darcy
about "Java floating point", where they also state the rule (that can be broken 
eventually):

"Evaluate arithmetic expressions and, except possibly for gargantuan 
arrays, declare temporary (local) variable ALL with the widest finite 
precision that is not too slow nor too narrow."

> Where did you get the idea that I meant "mathematically provable safe
> optimisation"? 

First to be sure we understand each other, by mathematically here, I 
reasonning in a mathematical fashion using the rules governing 
floating point computation and trying to assert that two different 
expressions will give the same result.

That is exactly your point, no. You do not want to allow 
optimisations that would not lead to the same results in boundary 
situations (and again, I agree that this is perfectly fine for some 
community of users, my point is that there is another communitie 
which does not care).

> Going into abstract considerations like NP-completness is beside the
> point.  

Agreed, I was not going into such considerations.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------


-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE7aEiPIzTj8qrxOU4RAg7OAJ9PnH74nWu7XiH23MteF3JrVfdPmQCfQw60
fY1qP8z2WT8l1kpBcABPL9I=
=YCbP
-----END PGP SIGNATURE-----