Date: Wed, 3 Mar 2021 19:25:12 +0000
>> 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
>> 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
Received on 2021-03-03 13:25:18