Second Draft "Unsafe fp optimizations" project description.

[Toon Moene]

Gabriel Dos_Reis wrote:

> Thanks for reiterating over this.
> 
> | Optimizations that change the meaning of floating point expressions
> 
> It would be more accurate and consistent with latter description to
> say  "Transformations" instead of "Optimizations".

Well, the reason I used the word "optimizations" here is that I agree
with Robert's point of view that there is little to gain from these
transformations if they aren't optimizations.  So I prefer to keep that
word.

> | Why would someone forego numerical accuracy for speed ? Isn't the fast but
> | wrong answer useless ?
> |
> | Unfortunately, this simple reasoning doesn't cut it in the Real World.
 
> I think the above description is somehow misleading.

> What about
> 
>   In numerical problems, there are roughly two kinds of computations:
>   1) those who need full precision in order to guarantee the results, and
>   2) those which are less sensible to occasional loss of accuracy.
> 
>   For the latter category, it is reasaonable to forego the numerical
>   accuracy for speed.

Yep, I was in a certain mood when I wrote the above - I'll rewrite it to
something equivalent to your suggestion above.  I'll also remove the jab
at "first person shooting game" - it was funny the first time, but it
gets old real fast ...

> | Open issues
> |
> | We should come up with a classification for complex arithmetic too. Just A/B
> | with A and B complex already has a couple of different possible evaluations.
> 
> We should also document cases where the transformations considered in
> this project depend on targets.  For example, Power does its
> floating point arithmetics in 64-bit whereas Sparc has two distinct
> categories of floating point arithmetic instructions -- a target may
> choose to use full 64-bits because it is faster (althought I doubt
> that is the case on Sparcs).

Certainly, that's a refinement we have to add later.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)