Boost logo

Boost :

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 ( 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
>> {
>> __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 p2, which states:
        The effect of instantiating the template complex for any type other than float, double, or long double is unspecified.

— Marshall

Boost list run by bdawes at, gregod at, cpdaniel at, john at