Re: 11706 vs ([lno] Canonical iv creation)

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

Roger Sayle wrote:
> On Sat, 13 Mar 2004, Richard Guenther wrote:
>
> > > Really interesting issue...
> > >
> > > Anyway, from a practical point of view I'm not really worried, since:
> > >
> > > 1- Glibc uses internally the very same algorithm, at least on x86 (just
> > >   checked).
> > >
> > > 2- Which requires O(log n) multiplications and is discussed by Knuth in
> > >   Sec. 4.6.3 of the second volume. You can find it almost *everywhere*,
> > >   for instance also in SGI's power.
> >
> > So there is no point in not optimizing ::pow(x, 4) without -ffast-math?
>
> There is a potential accuracy problem, which is why GCC doesn't inline
> ::pow(x,4) without -ffast-math.

[snip]

> Whether libstdc++-v3 can be more pragmatic than GCC about system library
> accuracy, and even whether -ffast-math is a reasonable default for the
> compiler (as its is with several commercial compilers), are larger
> arguments.  I doubt anyone would practically use a method more accurate
> than two multiplications to implement pow(x,4).  So I agree with Paolo's
> disclaimer "from a practical point of view I'm not really worried.." :>
>
> I hope this helps,

I'm aware of the rouding problems and am not worried about these.  But I 
am worried about having ::pow() and std::pow() produce different results 
for same arguments.  So the question is, does the standard say anything 
about this?  Also, as ::pow() with -ffast-math optimizes better than 
std::pow() for constant exponent, the question is again why we don't use 
::pow() for std::pow() ... which would also be faster in compilation speed.

We might even use SIMD operations (if available) to speed up -ffast-math 
::pow()?

Thanks for the explanations,

Richard.