Re: wrong result in complex pow

From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2021-02-05 17:50:08

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