Davis,

Thanks for the link to the cpython code. That's quite conclusive, and I can see the logic of that approach.

Can you think of a relatively safe way to get C++ to play nicely with the evaluation of these "tiny imaginary components are OK" problem? I get that a^b is "problematic" (to say the least) for a complex and b non-integer, but that's the problem I'm banging my head against at the moment.

Ian

-----Original Message-----
From: Herring, Davis <herring_at_[hidden]>
Sent: Wednesday, March 3, 2021 2:25 PM
To: Peter Sommerlad (C++) <peter.cpp_at_[hidden]>
Cc: Bell, Ian H. (Fed) <ian.bell_at_[hidden]>; std-discussion_at_[hidden]; sci_at_[hidden]
Subject: Re: [isocpp-sci] [std-discussion] Problems with pow(std::complex<T>, double)

>> using an integral 2nd argument to pow() solves the issue. May be
>> python is optimizing by checking that 2.0 is actually integral.

This is exactly what happens <https://github.com/python/cpython/blob/master/Objects/complexobject.c#L530>. In a similar, albeit static, fashion, libstdc++ has retained the int overload (removed in C++11) for similar reasons <https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/complex#L1011>.

> Taking the generic definition of complex pow function I can confirm
> that the pow() implementation is carrying the same error. May be, what
> you attempt is just beyond reasonable precision to expect from floating point.

The problem is that the function being differentiated intermixes the real and imaginary components of its input (when implemented as appropriate for floating-point inputs) via converting it to polar form. That completely defeats the "tiny imaginary components are OK" idea.

Davis