Re: wrong result in complex pow

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2021-05-01 21:00:15

Hello Chris,
do you already know how you want to realized the new implementation? There are several options:
a) template specialization (as before):
 - write all functions yourself
 - use the functions of libquadmath (gcc+clang), but not all of them are available, so you would have to write some yourself anyway. I also don't know if the intel compiler has any.
b) implement completely via template

Both have advantages and disadvantages
a)
Advantages: you don't have to take care of everything yourself but can use standard functions that have been tested
Disadvantages: inflexible, everything has to be rewritten for each additional template specialization; DRY, contradicts the template idea
b)
Advantages: flexible, no violation of the DRY principle; if errors occur, 
they only have to be corrected at EXACTLY ONE point and not in EVERY template specialization etc.
Disadvantages: high initial effort

Of course i prefer variant b. But i want to go into that: originally i only planned to write classes/functions for dual and splitcomplex numbers. These should meet the requirements:
- exactly + error handling (i have to do a lot more :-)
- fast
- constexpr

Since all 3 classes (scomplex, complex, dual) are similar, it makes sense 
to put them on a common code base. This is definitely NOT useful:
template <typename T> class scomplex {T r, i; };
template <typename T> class complex {T r, i; };
template <typename T> class dual {T r, i; };

After a lot of trial and error, i came to the conclusion that it is only possible this way (principle):
template <typename Type, size_t Size> class simd : public std::array<Type, Size>
{
functions/operators
};
and then
template <typename Type> class scomplex {simd<Type, 2> value;};
template <typename Type> class complex {simd<Type, 2> value;};
template <typename Type> class dual {simd<Type, 2> value;};

This has a lot of advantages:
- It can be guaranteed that the real and imag values ​​are in direct succession in the memory and that the autovectorization works 
better
- a number of functions/operators can simply use the simd functions/operators (e.g. i came across a bug in the autovectorizers of gcc+clang, which 
i can work around in a central location)
- operator[] and std::get can be made available; that becomes interesting 
if you also implement quaternion, octonionen, sedenion etc.
- type conversions can also be handled centrally in simd

In my current implementations i go even further:
1) std::execution::x can be specified for simd (for which I had to extend 
it for constexpr)
2) reinterpreted the math-functions:
- it drives me crazy if the result types do not match the argument, e.g.
 std::sin(Float) -> Float
 std::sin(Integer) -> Float
 std::sin(std::complex<Float>) -> std::complex <Float>
 std::sin(std::complex<Integer>) -> std::complex <Integer>
- now there is only one variant - WYCIWYG "What You Call Is What You Get":
 std::math::sin(Type) -> Type
 std::math::sin(std::math::complex<Type>) -> std::math::complex <Type>
 where you can set centrally whether rounding or shortening should be made for Float->Integer. Otherwise, for example, std::math::sin(integer) would (almost) always be 0.
3) retrofitted some missing functions
 - cot, sec, csc ...
 - inv 1/x, can be optimized for s/complex, dual etc.
 - rounding
 - classifiacation
 - and more

My goal is to provide all math and special functions constexpr for scalar 
types, scomplex, complex and dual (later then quaternion, octonionen, sedenion, ...). A hell of a lot of effort. But I think that you want to do that too - we could help each other and learn a lot.

@John
can you provide in boost/math/constants:
root(5)
1/root(5)
psi=1-phi

zero=0
one=1
two=2
three=3
four=4
five=5
ten=10

quarter=0.25

This is useful to guarantee that the values are constexpr.

thx
Gero

Am 19.04.21 um 17:28 schrieb Christopher Kormanyos:
>> i see that the pow-bug
>> (https://github.com/boostorg/math/issues/506 <https://github.com/boostorg/math/issues/506>)
>> is also included in 1.76
> 
> Hi Gero,
> 
> Thank you for following up on this.
> 
> You are correct.
> 
> The state of that issue is *open*, which means,
> unfortunately, that I have not yet fixed it.
> 
> The intent is to gather outstanding related
> points, bug-lets and the like and fix these
> en-masse in a more dedicated drive
> forward.
> 
> The time for me to drive forward on this
> is rapidly approaching. The deal is that
> 1.76 was full of many larger organizationsl
> and code-technical efforts in both Math
> as well as Multiprecision, followed by
> continued cleanup to this very day.
> 
> Forward mothion on this issue is planned
> forthcoming.
> 
> kind regards, Chris