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 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
