## STD-DISCUSSION | |

**Subject:** Re: [isocpp-sci] Problems with pow(std::complex<T>, double)

**From:** Peter C++ (*peter.cpp_at_[hidden]*)

**Date:** 2021-03-03 14:02:38

**Next message:**Hyman Rosen: "Re: Problems with pow(std::complex<T>, double)"**Previous message:**Bell, Ian H. (Fed): "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"**In reply to:**Bell, Ian H. (Fed): "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"**Next in thread:**Mark Hoemmen: "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"**Reply:**Mark Hoemmen: "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"

while not a cure, try complex<long double> if that gives you more precision on your system.

Sent from Peter Sommerlad's iPad

+41 79 432 23 32

> On 3 Mar 2021, at 20:52, Bell, Ian H. (Fed) <ian.bell_at_[hidden]> wrote:

>

> ï»¿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

**Next message:**Hyman Rosen: "Re: Problems with pow(std::complex<T>, double)"**Previous message:**Bell, Ian H. (Fed): "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"**In reply to:**Bell, Ian H. (Fed): "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"**Next in thread:**Mark Hoemmen: "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"**Reply:**Mark Hoemmen: "Re: [isocpp-sci] Problems with pow(std::complex<T>, double)"

STD-DISCUSSION list run by std-discussion-owner@lists.isocpp.org