From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2023-04-14 13:02:13
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/special_tut/special_tut_impl.html 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