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 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 class simd : public std::array
{
functions/operators
};
and then
template <typename Type> class scomplex {simd value;};
template <typename Type> class complex {simd value;};
template <typename Type> class dual {simd 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
