Date: Wed, 3 Mar 2021 22:37:05 +0000
Thanks everyone for digging into my simple problem. I wish there were a simple solution, but sadly that doesn't seem to be the case. My colleague recommended to move the discontinuity in log to the imaginary axis, which would help in this case, but cause new trouble for x=0. If only the magic of complex step derivatives was without any limitations such as these.
Ian
-----Original Message-----
From: Mark Hoemmen <mhoemmen_at_[hidden]>
Sent: Wednesday, March 3, 2021 5:32 PM
To: sci_at_[hidden]ocpp.org; Bell, Ian H. (Fed) <ian.bell_at_nist.gov>
Cc: Peter C++ <peter.cpp_at_sommerlad.ch>; std-discussion_at_lists.isocpp.org
Subject: Re: [isocpp-sci] [std-discussion] Problems with pow(std::complex<T>, double)
complex<long double> does help a little bit: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2Fdj9cnv&data=04%7C01%7Cian.bell%40nist.gov%7C6874fc90e64c428796a408d8de942793%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637504075192077530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jn%2FPA%2FeJ9T6878D43J8npG60ED76v8v%2F7cMmr8TSmJQ%3D&reserved=0
Davis pointed out that mixing the tiny imaginary part with the not-tiny real part is the problem. That means that the best you can hope for is a small normwise forward error, which we do get (the last thing printed in the above example). Generally, getting pointwise small errors is harder than getting normwise small errors.
mfh
On 3/3/2021 13:02, Peter C++ via Sci wrote:
> 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_nist.gov> 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_lanl.gov>
>> Sent: Wednesday, March 3, 2021 2:25 PM
>> To: Peter Sommerlad (C++) <peter.cpp_at_sommerlad.ch>
>> Cc: Bell, Ian H. (Fed) <ian.bell_at_nist.gov>; std-discussion_at_lists.isocpp.org; sci_at_lists.isocpp.org
>> 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
> _______________________________________________
> Sci mailing list
> Sci_at_[hidden]
> Subscription: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsci&data=04%7C01%7Cian.bell%40nist.gov%7C6874fc90e64c428796a408d8de942793%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637504075192077530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1WSNt83%2FHoTfZa2idoEyERDRxRrZ%2FANMQtjqr6PoEf4%3D&reserved=0
> Link to this post: https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fsci%2F2021%2F03%2F0381.php&data=04%7C01%7Cian.bell%40nist.gov%7C6874fc90e64c428796a408d8de942793%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637504075192087488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1n7Nbetv9fQabOw7mCMypeOsyxIFIbEcXaema7lsjzw%3D&reserved=0
Ian
-----Original Message-----
From: Mark Hoemmen <mhoemmen_at_[hidden]>
Sent: Wednesday, March 3, 2021 5:32 PM
To: sci_at_[hidden]ocpp.org; Bell, Ian H. (Fed) <ian.bell_at_nist.gov>
Cc: Peter C++ <peter.cpp_at_sommerlad.ch>; std-discussion_at_lists.isocpp.org
Subject: Re: [isocpp-sci] [std-discussion] Problems with pow(std::complex<T>, double)
complex<long double> does help a little bit: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2Fdj9cnv&data=04%7C01%7Cian.bell%40nist.gov%7C6874fc90e64c428796a408d8de942793%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637504075192077530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jn%2FPA%2FeJ9T6878D43J8npG60ED76v8v%2F7cMmr8TSmJQ%3D&reserved=0
Davis pointed out that mixing the tiny imaginary part with the not-tiny real part is the problem. That means that the best you can hope for is a small normwise forward error, which we do get (the last thing printed in the above example). Generally, getting pointwise small errors is harder than getting normwise small errors.
mfh
On 3/3/2021 13:02, Peter C++ via Sci wrote:
> 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_nist.gov> 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_lanl.gov>
>> Sent: Wednesday, March 3, 2021 2:25 PM
>> To: Peter Sommerlad (C++) <peter.cpp_at_sommerlad.ch>
>> Cc: Bell, Ian H. (Fed) <ian.bell_at_nist.gov>; std-discussion_at_lists.isocpp.org; sci_at_lists.isocpp.org
>> 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
> _______________________________________________
> Sci mailing list
> Sci_at_[hidden]
> Subscription: https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsci&data=04%7C01%7Cian.bell%40nist.gov%7C6874fc90e64c428796a408d8de942793%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637504075192077530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1WSNt83%2FHoTfZa2idoEyERDRxRrZ%2FANMQtjqr6PoEf4%3D&reserved=0
> Link to this post: https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fsci%2F2021%2F03%2F0381.php&data=04%7C01%7Cian.bell%40nist.gov%7C6874fc90e64c428796a408d8de942793%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637504075192087488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1n7Nbetv9fQabOw7mCMypeOsyxIFIbEcXaema7lsjzw%3D&reserved=0
Received on 2021-03-03 16:37:13