This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC beaten by ICC in stupid trig test!
Paul Koning wrote:
It's obvious that you can construct pathological cases where you end
up with zero bits of accuracy. That doesn't justify the conclusion
that -ffast-math should avoid transformations where this may happen.
Otherwise you might as well get rid of -ffast-math -- which would be a
major mistake.
What's not so obvious (clearly) is that these are not pathological
cases. On the contrary, it is all to easy to run into them. It is
most misleading to present a view to casual fpt programmers that
-ffast-math is unlikely to run into anomolies except in pathological
cases, and that they can reasonably expect just minor impact on
precision.
Good advice given here by someone that gives a little more confidence
is to run a range of tests with and without the option to see what
effects it has.
Incidentally, it is equally trivial to construct a pathological case
where the statement as written has zero bits of accuracy and the
transformation is much more accurate.
And that gets to the heart of the problem. When I write:
(a + b) + c;
I get *exactly* the precise fpt result that I am asking for, your
statement that a + (b + c) might be more accurate is only true if
you persist in regarding such expressions as inaccurate real
arithmetic, but competent floating-point programmers don't think
of things this way, and they write the sequence of operations
that they want to compute. So replacing (a+b)+c with a+(b+c)
NEVER improves the accuracy, it merely computes the wrong result!
Now going back to the list of issues, there are big differences
between various optimizations. For example, increased accuracy
and range are not necessarily a problem, although it is very
nice, as in Ada, to have individual control.
Ada specifically allows extra precision. In some cases extra
precision can indeed be a menace (one of the problems with
hex fpt arithmetic is precisely that the precision is variable).
But for many algorithms it does indeed not change the error
bounds. In Ada, you can write
Long_Float'Machine (A + B);
to force the result A+B to be exactly represented in standard
Long_Float format (i.e. remove the extra precision). It would
be nice to have a way of doing this in C.
paul