Am 12.04.23 um 13:29 schrieb Matt Borland:
c) constexpr I want to upgrade some functions in boost::math. How should/can I handle constexpr there? My problem is: - in gcc almost all math functions are constexpr - otherwise only some math functions with C++23 are constexpr Now it would be suboptimal not to use constexpr just because it is currently not in the standard. - If I don't define the additional functions as constexpr or stick strictly to the standard, performance might be wasted, which I don't want. - Can I simply define the additional functions with constexpr/BOOST_CXX14_CONSTEXPR? In case of an error there will be the standard-error "not constexpr".
All of the cmath functions that are specified to be constexpr in C++23 can be used with C++17 here: https://github.com/boostorg/math/tree/develop/include/boost/math/ccmath https://github.com/boostorg/math/tree/develop/include/boost/math/ccmath. If you would like to submit PRs for additional functions they are welcome. With the transcendental functions accuracy quickly becomes an issue: https://members.loria.fr/PZimmermann/papers/accuracy.pdf https://members.loria.fr/PZimmermann/papers/accuracy.pdf
d) implementation In https://www.boost.org/doc/libs/1_82_0_beta1/libs/math/doc/html/math_toolkit/... you describe how to implement a new math function. Is this still up to date or is it necessary for simple functions? E.g. cot -> 1/tan.
That is generally correct. If this is for the implementation of constexpr cmath functions I would follow the implementations that can be found in the linked ccmath folder.
Matt
Hi Matt, Thanks for your comments. But I don't want to go that far, since the rest of the math functions will hopefully be constexpr with C++26 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1383r1.pdf). An implementation in ccmath would be very elaborate. My questions were related to how I can now provide additional math functions without much effort; to stay with the cot example (simplified): 1) without constexpr template <typename Type> inline auto cot(const Type x) noexcept { return 1/std::tan(x); } This would have the disadvantage that performance might be wasted if the compiler already provides std::tan constexpr (e.g. gcc). 2) "optimistic" with constexpr template <typename Type> inline constexpr auto cot ... constexpr auto y = cot(2); // gcc ok else error "not constexpr" This may give a CT error. The question is if this would be acceptable from your side. 3) additional macro e.g. BOOST_MATH_CONSTEXPR #if (BOOST_GCC && __cplusplus >= 201103L) || (defined(__cpp_lib_constexpr_cmath) && __cpp_lib_constexpr_cmath >= 202202L) #define BOOST_MATH_CONSTEXPR constexpr #else #define BOOST_MATH_CONSTEXPR #endif template <typename Type> inline BOOST_MATH_CONSTEXPR auto cot ... BOOST_MATH_CONSTEXPR auto y = cot(2); Disadvantage: the macro must always be kept up to date (maintenance effort). Which would be the best solution? thx Gero