Re: wrong result in complex pow

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2021-02-03 19:21:55

 >> I patched this about as far as I'd like to go
> Hello Chris,> your patch doesn't seem to be working properly> yet. I also noticed that there is the same problem> with NaN and inf (and zeros?) for> pow(complex, complex). I'm currently working> on tests for all pow functions and patches.> Hope I'll get this ready soon and send it to you. > thx
> Gero
You are right. Thanks for any help you cancontribute.
If I look more critically at the file, I think theremight be other functions that could benefit fromsome increased handling of special argumentsNan, inf, zero real/imag. These include sqrt,log, log10, atan, and maybe a few others.
I might have underestimated the potentialfor improvement of this file and would nowwonder if a more in-depth refactoringis a wise idea? Compromise on improvementsof risk of breaking existing use in community?

Thoughts?
Kind regards, Chris

    On Wednesday, February 3, 2021, 1:31:48 AM GMT+1, Gero Peterhoff <g.peterhoff_at_[hidden]> wrote:  
 
 Hello Chris,
your patch doesn't seem to be working properly yet. I also noticed that there is the same problem with NaN and inf (and zeros?) for pow(complex, complex). I'm currently working on tests for all pow functions and patches. Hope I'll get this ready soon and send it to you. 

thx
Gero

Am 01.02.21 um 14:41 schrieb Christopher Kormanyos:
>>>Â noticed that my simple patch with base=0
>>> doesn't work.
> 
>> Thanks Gero.
>> Yes. I am trying a patch that handles zero explicitly.
>> I'm not quite sure if all zeros, NaNs and Infinities
>> are correct yet,
> 
> Gero,
> I patched this about as far as I'd like to go
> for this particular issue, added relevant
> tests. Underway, I did find that more
> possible work with zero, inf, NaN parameters
> that *could* be done in that particular header,
> but I will not modify these at the moment.
> This is because there are not a lot of requests
> for changes. I'd probably end up breaking
> existing code if I tried to clean up all
> kinds of edge cases that my eyes happened
> across.
> 
> That being said, the exact issue that you
> have pointed out and addressed in this
> thread on the board is being handled
> in the PR here:
> https://github.com/boostorg/math/pull/507 <https://github.com/boostorg/math/pull/507>
> 
> ... with fixed code here:
> https://github.com/boostorg/math/blob/e3cc94a580f3d1282578b0c31f985a392c866f19/include/boost/math/cstdfloat/cstdfloat_complex_std.hpp#L509 <https://github.com/boostorg/math/blob/e3cc94a580f3d1282578b0c31f985a392c866f19/include/boost/math/cstdfloat/cstdfloat_complex_std.hpp#L509>
> 
> Gero, if you get a chance, could you
> give the patch a try? It will expectedly be
> merged in and available in the next release.
> 
> Kind regards, Chris
> 
> On Sunday, January 31, 2021, 3:22:53 PM GMT+1, Christopher Kormanyos <e_float_at_[hidden]> wrote:
> 
> 
>> noticed that my simple patch with base=0
>> doesn't work.
> 
> Thanks Gero.
> 
> Yes. I am trying a patch that handles zero explicitly.
> I'm not quite sure if all zeros, NaNs and Infinities
> are correct yet,... But the patch is generally
> moving toward the fix shown in the link below...
> 
> If you get a chance, could you try that patch
> from the branch linked below?
> 
> https://github.com/boostorg/math/blob/2eac693e12547c1ca26800c2403e4e50f62d29bd/include/boost/math/cstdfloat/cstdfloat_complex_std.hpp#L512 <https://github.com/boostorg/math/blob/2eac693e12547c1ca26800c2403e4e50f62d29bd/include/boost/math/cstdfloat/cstdfloat_complex_std.hpp#L512>
> 
> 
> Kind regards, Chris
> 
> 
> On Sunday, January 31, 2021, 2:17:32 PM GMT+1, Gero Peterhoff <g.peterhoff_at_[hidden]> wrote:
> 
> 
> Hello Christopher,
> I just noticed that my simple patch with base=0 doesn't work. It is probably not that simple.
> https://godbolt.org/z/8Me15Y <https://godbolt.org/z/8Me15Y>
> 
> regards
> Gero
> 
> Am 30.01.21 um 16:22 schrieb Christopher Kormanyos:
>>>>Â the pow-function pow(scalar, complex) in
>>>> boost/math/cstdfloat/cstdfloat_complex_std.hpp
>>>> get wrong result.
>>
>>> Thanks Gero,
>>> I am on the go, but later today, I'll add this
>>> as an issue in Git and kick off the discussion
>>> for the fix with the colleagues.
>>
>> A new issue can be found here, but it
>> is not clear which code example elicits
>> the unexpected behavior.
>>
>> https://github.com/boostorg/math/issues/506 <https://github.com/boostorg/math/issues/506 ><https://github.com/boostorg/math/issues/506 <https://github.com/boostorg/math/issues/506>>
>>
>>
>> On Thursday, January 28, 2021, 12:55:59 PM GMT+1, Gero Peterhoff via Boost <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
>>
>>
>> Hello,
>> the pow-function pow(scalar, complex) in boost/math/cstdfloat/cstdfloat_complex_std.hpp get wrong result.
>>
>> Current implementation:
>> inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> pow(const BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE& x,
>> Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& a)
>> {
>> Â  return std::exp(a * std::log(x));
>> }
>>
>> I think that's correct:
>> inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> pow(const BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE& x,
>> Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& a)
>> {
>> Â  return std::exp(a * std::log(complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>(x)));
>> }
>>
>> regards
>> Gero
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost ><http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>>
>