This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Draft "Unsafe fp optimizations" project description. 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 - - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77:
Join GNU Fortran 95: (under construction)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]