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

[Marc Glisse]

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