
Boost : 
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 20210503 20:44:45
> provide all math and special functions> constexpr for scalar types, scomplex,> complex
I will start with 506 with the noteswe made here:https://github.com/boostorg/math/issues/506
I think I can commit to that level in 506.I'm not sure if I will have time forother numerical types in this areain the next time, as GSoC willalso begin.
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 mathfunctions:
 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=1phi
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 powbug
>> (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, buglets and the like and fix these
> enmasse 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 codetechnical 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk