Re: round-off error in std::pow(std::complex<T>, double) in C++11

[Marc Glisse <marc dot glisse at inria dot fr>]

On Fri, 25 Jan 2013, Paolo Carlini wrote:

> On 01/25/2013 05:18 PM, Paolo Carlini wrote:
> > On 01/25/2013 04:44 PM, Paolo Carlini wrote:
> > > .. oops, I just noticed what Marc suggested in the PR about changing 
> > > pow(const complex<>&, const _Tp&) to *actually* forward to the complex 
> > > builtins when not fast math. That seems a good idea
> > I have to add to this, however, that unless I did something badly wrong in 
> > a quick prototype, simply forwarding to the (complex, complex) builtin 
> > would *not* fix the round-off issue for this specific example. In other 
> > terms it seems that to actually get 0 we really have to handle separately 
> > (small) integer exponents, as Marc mentioned in the PR. Then again, is this 
> > overall a libstdc++ issue or it would make sense to have the (..., int) 
> > overloads restored at the *ISO* level?

There are 2 possible things we can want for pow(z, 4): be fast, or be the 
correctly rounded value. I would (over-)interpret the presence of an int 
overload in the standard as a hint that we want the first, and its absence 
(or the C++11 wording) as a hint in favor of the second.

> ... or, alternately, just forward to the builtins (at least when not fast 
> math) and have the builtins handle in an optimized way an exponent which is a 
> small integer.

Implementing this optimization in the compiler when the exponent is a 
compile-time constant seems like a good and simple idea in any case :-)

> I'm not at all convinced that when the Standard removes the 
> (..., int) overloads we want to red-add the overloads back in the library as 
> an implementation detail.

The standard didn't remove it, it added hundreds of others so the int 
overload is now one among many covered by generic text.

--
Marc Glisse