Re: wrong result in complex pow

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2021-02-05 19:41:34

 > 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 <boost_at_[hidden]> wrote:  
 
 On Feb 5, 2021, at 9:00 AM, John Maddock via Boost <boost_at_[hidden]> 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