
Boost : 
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 20210205 06:02:37
> 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 builtins 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<FPType>? 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 stdmath functions missing> for complex; specialfunctions complete> (also applies to std::valarray)?
> I want to add such things in my mathlib,> 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 128bitfloat 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 indepthfor 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 <g.peterhoff_at_[hidden]> 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/MathLibraryRoutines.html#MathLibraryRoutines) 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 builtins 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<FPType>? 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 stdmath functions missing for complex; specialfunctions complete (also applies to std::valarray)?
I want to add such things in my mathlib, 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 boostmathlib 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 indepth 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 <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 ><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 <e_float_at_[hidden] <mailto: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 ><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] <mailto: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 ><https://godbolt.org/z/8Me15Y <https://godbolt.org/z/8Me15Y>>
>>
>> regards
>> Gero
>>
>> Am 30.01.21 um 16:22 schrieb Christopher Kormanyos:
>>>>>Â the powfunction 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 <boost_at_[hidden] <mailto:boost_at_[hidden]> <mailto:boost_at_[hidden] <mailto:boost_at_[hidden]>>> wrote:
>
>>>
>>>
>>> Hello,
>>> the powfunction 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>>>
>>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk