This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Draft "Unsafe fp optimizations" project description.
- To: dewar at gnat dot com
- Subject: Re: Draft "Unsafe fp optimizations" project description.
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Sat, 04 Aug 2001 17:19:21 +0200
- CC: gcc at gcc dot gnu dot org, lucier at math dot purdue dot edu
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <20010804134535.DDEF3F2B6C@nile.gnat.com>
dewar@gnat.com wrote:
> Some comments
Thanks !
> Can't we have this in plain text, HTML is such a pain in the neck!
Well, I hoped to review the *file* as I was preparing it for the web
page repository, but given the problems in sending it I doubt this was a
very clever decision.
> "does not introduce surprises"
>
> is stronger than
>
> "all of its numerical effects are well-documented"
The problem is: What constitutes a surprise ? If I ask for "force
denormals to zero" I know that I might run into a divide-by-zero error,
so I do not think of that as a surprise. To make it "not-a-surprise" to
anyone, it should be documented.
> There are also some claims that are quite wrong, I will try to go
> over this document further.
>
> First, be careful not to imply that the only issue is being a few
> ULP off, we know that is not always the case.
I tried to confine that to the chapter "Rationale" to make it clear *why
someone would consider this class of transformations*. I certainly do
not want to imply that it is the only problem. Perhaps you have a
suggestion for refrasing that part ?
> Second, your comment about rounding modes is wrong, I can easily
> see applications which work find with rounding, even if some liberties
> are taken with some rearrangements, but where going to truncating
> arithmetic would introduce biases that would make the results
> meaningless. It would be interesting to see if the well known
> case of computing orbits of Pluto (where the difference between
> biased and unbiased rounding made a difference -- much more
> surprising) would have been robust wrt to some of the transformations
> under discussion.
Thanks - I should choose a more careful sentence here. Perhaps I best
just remove it.
> Rearrangements with no effects should not be mentioned or discussed, they
> have nothing to do with the issue at hand,
Yep, it is distracting because it's different than the others. I
thought I'd found a nice example, but indeed, -A+B -> B-A is not it. On
the changes with constants I should probably add a chapter (to explain
why that case is different).
> Rearrangements whose only effect is a loss of accuracy
> An example is cases of multiplication by the reciprocal instead of
> division in cases where overflow is not possible.
Hmm, yes, but because of the condition I put it in a different class.
> Another good examle is a*a*a*a => (a*a)**2 which can lose accuracy but
> that's the only downside.
Good one - I'll see how I can generalize this.
> > Example: A/B/C -> A/(B*C). Will overflow for about half of the possible choices for B and C for
> > which the original didn't overflow.
>
> That's quite wrong, you have to be close to max_real, half is way way
> overstating the case.
This has to be formulated much more careful indeed. The results depend
on all three inputs.
> One thing about this *document* is that even if it is going to be used
> by people who are not floating-point experts, it had better be written
> or at least thoroughly reviewed by someone who is :-)
There are quite a few people on the GCC mailing list who are better
numericists than I am. That's OK, because that means that I *can* start
this discussion here. If I had to find it out all by myself it might
have cost several months of study.
> What I wrote above by the way is definitely NOT a thorough review, just
> some observations from a quickscan through HTML junk!
Well, we probably have to go to several iterations before it is fine,
but given the discussions on the mailing list I felt that we definitely
needed something (that's less ephemeral than the mailing lists) to lay
down our consensus on this issue.
Thanks for your input !
--
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)