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