wrong result in complex pow

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

wrong result in complex pow

Boost - Dev mailing list
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

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 > the pow-function pow(scalar, complex) in> boost/math/cstdfloat/cstdfloat_complex_std.hpp> get wrong result.
Thanks Gero,
Good catch. This does seem like a bug.I am on the go, but later today, I'll add thisas an issue in Git and kick off the discussionfor the fix with the colleagues.
Kind regards, Chris

    On Thursday, January 28, 2021, 12:55:59 PM GMT+1, Gero Peterhoff via Boost <[hidden email]> 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
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
 >> 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 itis not clear which code example elicitsthe unexpected behavior.

https://github.com/boostorg/math/issues/506

    On Thursday, January 28, 2021, 12:55:59 PM GMT+1, Gero Peterhoff via Boost <[hidden email]> 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
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
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

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>
>
>
> On Thursday, January 28, 2021, 12:55:59 PM GMT+1, Gero Peterhoff via Boost <[hidden email]> 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>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 > 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 Infinitiesare correct yet,... But the patch is generallymoving toward the fix shown in the link below...
If you get a chance, could you try that patchfrom the branch linked below?

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 <[hidden email]> 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

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>
>
>
> On Thursday, January 28, 2021, 12:55:59 PM GMT+1, Gero Peterhoff via Boost <[hidden email]> 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>

 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
  >> 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 relevanttests. Underway, I did find that morepossible work with zero, inf, NaN parametersthat *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 requestsfor changes. I'd probably end up breakingexisting code if I tried to clean up allkinds of edge cases that my eyes happenedacross.
That being said, the exact issue that youhave pointed out and addressed in thisthread on the board is being handledin the PR here:
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
Gero, if you get a chance, could yougive the patch a try? It will expectedly bemerged in and available in the next release.
Kind regards, Chris
    On Sunday, January 31, 2021, 3:22:53 PM GMT+1, Christopher Kormanyos <[hidden email]> 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 Infinitiesare correct yet,... But the patch is generallymoving toward the fix shown in the link below...
If you get a chance, could you try that patchfrom the branch linked below?

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 <[hidden email]> 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

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>
>
>
> On Thursday, January 28, 2021, 12:55:59 PM GMT+1, Gero Peterhoff via Boost <[hidden email]> 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>

   

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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>>
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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>>
>

 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
Christopher Kormanyos via Boost said:     (by the date of Wed, 3 Feb 2021 19:21:55 +0000 (UTC))

> If I look more critically at the file, I think theremight be other
> functions that could benefit fromsome increased handling of special
> arguments Nan, 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 now wonder if a more
> in-depth refactoringis a wise idea? Compromise on improvementsof
> risk of breaking existing use in community?


How about adding a trait to the floating point type, whether you want
exceptions, or any kind of error control. Default value of the trait
is the backward compatibility. New and old users are both happy.



best regards
--
# Janek Kozicki                              http://janek.kozicki.pl/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hello Chris,
Unfortunately, a few things have come up with me so that I (probably) won't be able to really help in the near future.
Some other functions (e.g. log, exp) also give incorrect results for some combinations of nan, inf and 0.
But I saw that gcc libquadmath (https://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html#Math-Library-Routines) offers some complex functions that work correctly. These could be used. But I don't know if clang, intel and/or other compilers can do that too.
example
inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> log(const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& x)
{
        __complex128
                res = __complex128{x.real(), x.imag()};
        res = clogq(res);
        return complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>{crealq(res), cimagq(res)};
}

I also noticed a few basic things, maybe you can say why that is:
- Why are there explicit complex classes for FP types, why is this not implemented completely via template? The advantage is that built-ins can be used, on the other hand, a separate class must be written for each FP type - with the problems we are currently having.
- Why are there missing template conversion ctors for the complex<FP-Type>? That will not do:
std::complex<int> ci{4711, 23};
std::complex<double> cd=ci;
or
std::complex<double> cd = std::complex<double>{ci};
but a ctor must be called explicitly
std::complex<double> cd=std::complex<double>{double(ci.real()), double(ci.imag())}; // prevent warnings
It's really annoying.
- Why are many std-math functions missing for complex; special-functions complete (also applies to std::valarray)?

I want to add such things in my math-lib, as far as possible everything constexpr. I also want to provide additional classes for dual and splitcomplex numbers (i²=0, i²=1, but it is far from complete - because it is quite extensive). Maybe these could also be included in boost. To do this, however, it would be necessary to convert the boost-math-lib to C++20, since some functions (or the distinction between dual, complex and splitcomplex - classes/functions) is only possible with concepts (otherwise unreasonable effort). I also need some additional typetraits.

thx
Gero

Am 03.02.21 um 20:21 schrieb Christopher Kormanyos:

>>> 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 can
> contribute.
>
> If I look more critically at the file, I think there
> might be other functions that could benefit from
> some increased handling of special arguments
> Nan, inf, zero real/imag. These include sqrt,
> log, log10, atan, and maybe a few others.
>
> I might have underestimated the potential
> for improvement of this file and would now
> wonder if a more in-depth refactoring
> is a wise idea? Compromise on improvements
> of risk of breaking existing use in community?
>
> Thoughts?
>
> Kind regards, Chris
>
>
>
> On Wednesday, February 3, 2021, 1:31:48 AM GMT+1, Gero Peterhoff <[hidden email]> 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 ><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 ><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 <[hidden email] <mailto:[hidden email]>> 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 ><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 <[hidden email] <mailto:[hidden email]>> 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 ><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 >><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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 >><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>>>
>>
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 > Some other functions (e.g. log, exp) also give> incorrect results for some combinations> of nan, inf and 0
Yes, I did also notice that.

> I also noticed a few basic things,> maybe you can say why that is:> - Why are there explicit complex classes> for FP types, why is this not implemented> completely via template? The advantage is> that built-ins can be used, on the other hand,> a separate class must be written for each> FP type - with the problems we are currently having.> - Why are there missing template conversion> ctors for the complex<FP-Type>? That will not do:> std::complex<int> ci{4711, 23};
> std::complex<double> cd=ci;
> or
> std::complex<double> cd = std::complex<double>{ci};
> but a ctor must be called explicitly
> std::complex<double> cd=std::complex<double>{double(ci.real()), double(ci.imag())}; // prevent warnings
> It's really annoying.
> - Why are many std-math functions missing> for complex; special-functions complete> (also applies to std::valarray)?
> I want to add such things in my math-lib,> as far as possible everything constexpr...
These are good questions and valid points.The files in question were written in 2013/14.In time since passed, we have two major changesincluding Multiprecision's own 128-bitfloat class and a complex adapter.
What need to do here is find out whatis thoday's proper niche for <cstdfloat.hpp>?And how can it be made more corrector less wrong, or more standards compliant,or however you want to put it?
I will look into a potential larger refactor.A lot of this action will get too in-depthfor the board. Tracking of any significantprogress will probably be handled on theGitHub platform.
Kind regards


    On Thursday, February 4, 2021, 9:23:42 PM GMT+1, Gero Peterhoff <[hidden email]> wrote:  
 
 Hello Chris,
Unfortunately, a few things have come up with me so that I (probably) won't be able to really help in the near future.
Some other functions (e.g. log, exp) also give incorrect results for some combinations of nan, inf and 0.
But I saw that gcc libquadmath (https://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html#Math-Library-Routines) offers some complex functions that work correctly. These could be used. But I don't know if clang, intel and/or other compilers can do that too.
example
inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> log(const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& x)
{
    __complex128
        res = __complex128{x.real(), x.imag()};
    res = clogq(res);
    return complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>{crealq(res), cimagq(res)};
}

I also noticed a few basic things, maybe you can say why that is:
- Why are there explicit complex classes for FP types, why is this not implemented completely via template? The advantage is that built-ins can be used, on the other hand, a separate class must be written for each FP type - with the problems we are currently having.
- Why are there missing template conversion ctors for the complex<FP-Type>? That will not do:
std::complex<int> ci{4711, 23};
std::complex<double> cd=ci;
or
std::complex<double> cd = std::complex<double>{ci};
but a ctor must be called explicitly
std::complex<double> cd=std::complex<double>{double(ci.real()), double(ci.imag())}; // prevent warnings
It's really annoying.
- Why are many std-math functions missing for complex; special-functions complete (also applies to std::valarray)?

I want to add such things in my math-lib, as far as possible everything constexpr. I also want to provide additional classes for dual and splitcomplex numbers (i²=0, i²=1, but it is far from complete - because it is quite extensive). Maybe these could also be included in boost. To do this, however, it would be necessary to convert the boost-math-lib to C++20, since some functions (or the distinction between dual, complex and splitcomplex - classes/functions) is only possible with concepts (otherwise unreasonable effort). I also need some additional typetraits.

thx
Gero

Am 03.02.21 um 20:21 schrieb Christopher Kormanyos:

>>> 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 can
> contribute.
>
> If I look more critically at the file, I think there
> might be other functions that could benefit from
> some increased handling of special arguments
> Nan, inf, zero real/imag. These include sqrt,
> log, log10, atan, and maybe a few others.
>
> I might have underestimated the potential
> for improvement of this file and would now
> wonder if a more in-depth refactoring
> is a wise idea? Compromise on improvements
> of risk of breaking existing use in community?
>
> Thoughts?
>
> Kind regards, Chris
>
>
>
> On Wednesday, February 3, 2021, 1:31:48 AM GMT+1, Gero Peterhoff <[hidden email]> 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 ><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 ><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 <[hidden email] <mailto:[hidden email]>> 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 ><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 <[hidden email] <mailto:[hidden email]>> 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 ><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 >><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 <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> 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 >><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>>>
>>
>

 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 04/02/2021 20:23, Gero Peterhoff via Boost wrote:
> Hello Chris,
> Unfortunately, a few things have come up with me so that I (probably) won't be able to really help in the near future.
> Some other functions (e.g. log, exp) also give incorrect results for some combinations of nan, inf and 0.

The place to check for this is C99 Annex G - but note that this is
non-normative so there will be implementations of std::complex which do
not do anything in particular in these cases... platforms too with no
infinity or NaN.

> But I saw that gcc libquadmath (https://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html#Math-Library-Routines) offers some complex functions that work correctly. These could be used. But I don't know if clang, intel and/or other compilers can do that too.
> example
> inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> log(const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& x)
> {
> __complex128
> res = __complex128{x.real(), x.imag()};
> res = clogq(res);
> return complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>{crealq(res), cimagq(res)};
> }
>
> I also noticed a few basic things, maybe you can say why that is:
> - Why are there explicit complex classes for FP types, why is this not implemented completely via template? The advantage is that built-ins can be used, on the other hand, a separate class must be written for each FP type - with the problems we are currently having.
This is all a question for the C++ committee, my speculation would be
that they wished to restrict the scope of std::complex to
float/double/long double.

> - Why are there missing template conversion ctors for the complex<FP-Type>? That will not do:
> std::complex<int> ci{4711, 23};
> std::complex<double> cd=ci;
> or
> std::complex<double> cd = std::complex<double>{ci};
> but a ctor must be called explicitly
> std::complex<double> cd=std::complex<double>{double(ci.real()), double(ci.imag())}; // prevent warnings
> It's really annoying.
> - Why are many std-math functions missing for complex; special-functions complete (also applies to std::valarray)?
>
> I want to add such things in my math-lib, as far as possible everything constexpr. I also want to provide additional classes for dual and splitcomplex numbers (i²=0, i²=1, but it is far from complete - because it is quite extensive). Maybe these could also be included in boost. To do this, however, it would be necessary to convert the boost-math-lib to C++20, since some functions (or the distinction between dual, complex and splitcomplex - classes/functions) is only possible with concepts (otherwise unreasonable effort). I also need some additional typetraits.

If you want to provide implementations for any complex valued special
functions we can take care of the algorithm overload selection -
enable_if will do fine, there's no need for concepts just yet.

Best John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
On Feb 5, 2021, at 9:00 AM, John Maddock via Boost <[hidden email]> wrote:

>
> On 04/02/2021 20:23, Gero Peterhoff via Boost wrote:
>> Hello Chris,
>> Unfortunately, a few things have come up with me so that I (probably) won't be able to really help in the near future.
>> Some other functions (e.g. log, exp) also give incorrect results for some combinations of nan, inf and 0.
>
> The place to check for this is C99 Annex G - but note that this is non-normative so there will be implementations of std::complex which do not do anything in particular in these cases... platforms too with no infinity or NaN.
>
>> But I saw that gcc libquadmath (https://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html#Math-Library-Routines) offers some complex functions that work correctly. These could be used. But I don't know if clang, intel and/or other compilers can do that too.
>> example
>> inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> log(const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& x)
>> {
>> __complex128
>> res = __complex128{x.real(), x.imag()};
>> res = clogq(res);
>> return complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>{crealq(res), cimagq(res)};
>> }
>>
>> I also noticed a few basic things, maybe you can say why that is:
>> - Why are there explicit complex classes for FP types, why is this not implemented completely via template? The advantage is that built-ins can be used, on the other hand, a separate class must be written for each FP type - with the problems we are currently having.
> This is all a question for the C++ committee, my speculation would be that they wished to restrict the scope of std::complex to float/double/long double.

I refer you to https://wg21.link/complex.numbers p2, which states:
        The effect of instantiating the template complex for any type other than float, double, or long double is unspecified.

— Marshall


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 > Some other functions (e.g. log, exp) also> give incorrect results
Based on this comment and all theother great comments comments so far,...This thread has motivated reformulationof the original change request.
It will be handled as a PR in Math here:https://github.com/boostorg/math/pull/507
Treating the full scope of necessarydiscussions might be best handledin the GitHub issue.

Thanks for getting the ball rollingon this and kind regards, Chris


   On Friday, February 5, 2021, 6:50:37 PM GMT+1, Marshall Clow via Boost <[hidden email]> wrote:  
 
 On Feb 5, 2021, at 9:00 AM, John Maddock via Boost <[hidden email]> wrote:

>
> On 04/02/2021 20:23, Gero Peterhoff via Boost wrote:
>> Hello Chris,
>> Unfortunately, a few things have come up with me so that I (probably) won't be able to really help in the near future.
>> Some other functions (e.g. log, exp) also give incorrect results for some combinations of nan, inf and 0.
>
> The place to check for this is C99 Annex G - but note that this is non-normative so there will be implementations of std::complex which do not do anything in particular in these cases... platforms too with no infinity or NaN.
>
>> But I saw that gcc libquadmath (https://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html#Math-Library-Routines) offers some complex functions that work correctly. These could be used. But I don't know if clang, intel and/or other compilers can do that too.
>> example
>> inline complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE> log(const complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>& x)
>> {
>>     __complex128
>>         res = __complex128{x.real(), x.imag()};
>>     res = clogq(res);
>>     return complex<BOOST_CSTDFLOAT_EXTENDED_COMPLEX_FLOAT_TYPE>{crealq(res), cimagq(res)};
>> }
>>
>> I also noticed a few basic things, maybe you can say why that is:
>> - Why are there explicit complex classes for FP types, why is this not implemented completely via template? The advantage is that built-ins can be used, on the other hand, a separate class must be written for each FP type - with the problems we are currently having.
> This is all a question for the C++ committee, my speculation would be that they wished to restrict the scope of std::complex to float/double/long double.

I refer you to https://wg21.link/complex.numbers p2, which states:
    The effect of instantiating the template complex for any type other than float, double, or long double is unspecified.

— Marshall


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Feb 5, 2021 at 10:50 AM Marshall Clow via Boost <
[hidden email]> wrote:

> On Feb 5, 2021, at 9:00 AM, John Maddock via Boost <[hidden email]>
> wrote:
> >
> >> I also noticed a few basic things, maybe you can say why that is:
> >> - Why are there explicit complex classes for FP types, why is this not
> implemented completely via template? The advantage is that built-ins can be
> used, on the other hand, a separate class must be written for each FP type
> - with the problems we are currently having.
> > This is all a question for the C++ committee, my speculation would be
> that they wished to restrict the scope of std::complex to float/double/long
> double.
>
> I refer you to https://wg21.link/complex.numbers p2, which states:
>         The effect of instantiating the template complex for any type
> other than float, double, or long double is unspecified.
>
> — Marshall
>

I will note that there is a proposal that might alter this stance:

https://wg21.link/P1467R4

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 > I will note that there is a proposal that> might alter this stance:> https://wg21.link/P1467R4
Oh thanks. This is great! It's goodto see the ball rolling on that one.

Personally, I would really enjoyto see floatN_t in C/C++ world. I was notaware of this particular proposal, which does,in fact, mention, revive and extend previous,partial (yet stalled) work by Bristow, Maddockand myself --- Floating-Point Typedefs HavingSpecified Widths - N1703.
In fact, the preliminary work in
https://github.com/boostorg/math/tree/develop/include/boost/math/cstdfloat
(which contains the original topic of this thread) attempts to providea sensible working model for floatN_t.
If ever desired to better align Boost withhttps://wg21.link/P1467R4as it progresses, please feel free to contactus (or me) in the future.

Kind regards, Chris






    On Saturday, February 6, 2021, 1:38:06 AM GMT+1, Jeff Garland via Boost <[hidden email]> wrote:  
 
 On Fri, Feb 5, 2021 at 10:50 AM Marshall Clow via Boost <
[hidden email]> wrote:

> On Feb 5, 2021, at 9:00 AM, John Maddock via Boost <[hidden email]>
> wrote:
> >
> >> I also noticed a few basic things, maybe you can say why that is:
> >> - Why are there explicit complex classes for FP types, why is this not
> implemented completely via template? The advantage is that built-ins can be
> used, on the other hand, a separate class must be written for each FP type
> - with the problems we are currently having.
> > This is all a question for the C++ committee, my speculation would be
> that they wished to restrict the scope of std::complex to float/double/long
> double.
>
> I refer you to https://wg21.link/complex.numbers p2, which states:
>        The effect of instantiating the template complex for any type
> other than float, double, or long double is unspecified.
>
> — Marshall
>

I will note that there is a proposal that might alter this stance:

https://wg21.link/P1467R4

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
That's the problem: the generic std::complex class has generic conversion ctors, the FP specializations don't. I don't understand why this is done.

Am 05.02.21 um 18:50 schrieb Marshall Clow via Boost:
> I refer you to https://wg21.link/complex.numbers p2, which states:
> The effect of instantiating the template complex for any type other than float, double, or long double is unspecified.
>
> — Marshall



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
On 08/02/2021 17:30, Gero Peterhoff via Boost wrote:
> That's the problem: the generic std::complex class has generic conversion ctors, the FP specializations don't. I don't understand why this is done.

Actually the generic template specification is redundant given that only
float/double/long double specializations are allowed.

BTW the specializations do have converting constructors, but they are
explicit when narrowing which is the right design IMO.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
It would be very desirable to implement all conversion ctors generically so that both directions work:
1)
std::complex<double> a{1.1, 2.2};
std::complex<int> b{a}; // works
2)
std::complex<int> a{1, 2};
std::complex<double> b{a}; // doesn't work
without explicit call
std::complex<double> b{a.real(), a.imag()};
or
std::complex<double> b{double(a.real()), double(a.imag())};
to prevent warnings.

This is cumbersome, confusing and a source of errors.

Am 08.02.21 um 19:04 schrieb John Maddock via Boost:
> On 08/02/2021 17:30, Gero Peterhoff via Boost wrote:
>> That's the problem: the generic std::complex class has generic conversion ctors, the FP specializations don't. I don't understand why this is done.
>
> Actually the generic template specification is redundant given that only float/double/long double specializations are allowed.
>
> BTW the specializations do have converting constructors, but they are explicit when narrowing which is the right design IMO.
>
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

OpenPGP_signature (243 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wrong result in complex pow

Boost - Dev mailing list
 > It would be very desirable to implement all> conversion ctors generically so that both> directions work...
The plan is to try to achieve generally the following:

*Interface model based on C++14 <complex>.

* Use C99 Annex G to guide us for the rightspecial values to return for arguments zero,INF, NaN?

Are those two top-level requirements OK,or at least a good start, more right (less wrong)?
Kind regards, Chris
    On Monday, February 8, 2021, 7:40:12 PM GMT+1, Gero Peterhoff via Boost <[hidden email]> wrote:  
 
 It would be very desirable to implement all conversion ctors generically so that both directions work:
1)
std::complex<double> a{1.1, 2.2};
std::complex<int> b{a}; // works
2)
std::complex<int> a{1, 2};
std::complex<double> b{a}; // doesn't work
without explicit call
std::complex<double> b{a.real(), a.imag()};
or
std::complex<double> b{double(a.real()), double(a.imag())};
to prevent warnings.

This is cumbersome, confusing and a source of errors.

Am 08.02.21 um 19:04 schrieb John Maddock via Boost:
> On 08/02/2021 17:30, Gero Peterhoff via Boost wrote:
>> That's the problem: the generic std::complex class has generic conversion ctors, the FP specializations don't. I don't understand why this is done.
>
> Actually the generic template specification is redundant given that only float/double/long double specializations are allowed.
>
> BTW the specializations do have converting constructors, but they are explicit when narrowing which is the right design IMO.
>
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost