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

[Marc Glisse]

On Sat, 26 Jan 2013, John W. Eaton wrote:

> On 01/25/2013 01:54 PM, Marc Glisse wrote:
>
>> Implementing this optimization in the compiler when the exponent is a
>> compile-time constant seems like a good and simple idea in any case :-)
>
> If that was done, would a function like
>
>  bool foo (std::complex<double>& x, int y)
>  {
>     return std::pow (x, y) == std::pow (x, 2);
>  }
>
> maybe return fals if called with y = 2, assuming the compiler could not 
> determine the value of y at compile time?

Yes, if the pow function is inaccurate (as in glibc). No with a correctly 
rounded pow function.

> That seems like a bad feature to me.

I wouldn't be surprised if this was already the case for a number of other 
functions, but other functions usually have a more accurate 
implementation so you don't notice it. But I can understand why that 
doesn't look good to you.

The most obvious case where this happens is constant propagation. The i^2 
example that started this thread is optimized to exactly -1 if the 
compiler sees both arguments as constants (it asks MPC for the exact 
result) and we use -O1 or higher. And as reported, it doesn't give -1 if 
this is computed either with the libstdc++ code or the glibc code.

-- 
Marc Glisse