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