Re: wrong result in complex pow

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2021-05-03 20:41:18

 > do you already know how you want to> realized the new implementation

Hi Gero. Thanks for responding and pleaseaccept my apologies for the late response.
The short answer to the queries above andsuggestions from your side, having muchdepth and information is that i plan toimprove (via refactor) for 1.77.
This is the only actual issue in Boostthat I have assigned to myself rightnow. I took some time to clean upsome projects in other domains,but expect to re-open work on thisissue shortly.
Kind regards, Chris
    On Saturday, May 1, 2021, 11:00:18 PM GMT+2, Gero Peterhoff <g.peterhoff_at_[hidden]> wrote:  
 
 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