Re: improve <boost/math/constants.hpp>

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2023-03-10 22:43:02

Am 10.03.23 um 22:39 schrieb Matt Borland:
> 
> 
>> On Mar 10, 2023, at 1:11 PM, Gero Peterhoff via Boost <boost_at_[hidden]> wrote:
>>
>> Hello,
>> * Problem description
>> The constants do not work with the C++23 FP types.
>>
>> * general hint
>> To prevent (more) warnings it is useful to introduce this macro:
>> #if defined(__STDCPP_FLOAT128_T__)
>> 	#define BOOST_FLOATMAX_SUFFIX F128
>> #elif defined(BOOST_CSTDFLOAT_FLOAT128_NATIVE_TYPE)
>> 	#define BOOST_FLOATMAX_SUFFIX Q
>> #else
>> 	#define BOOST_FLOATMAX_SUFFIX L
>> #endif
>>
>> * question
>> In constants the namespaces float/double/long_double_constant+detail are created type dependent (in case the value constexpr can be requested). If the value cannot be requested constexpr the conversion is finally done by boost::lexical_cast.
>> But the implementation is very complex. I have a better one - but I may have missed things.
>> If so - which would they be?
>>
>> * My solution (BOOST_MAKE_MATH_CONSTANT)
>> see constants_more.hpp, advantages:
>> - works with all FP types
>> - compatible to the existing implementation CONSTANT<Type>()
>> - is clear/understandable (comments)
>> - may need only one additional namespace static_constants (and not 4)
>> - provides the constants additionally as CONSTANT_v (constexpr) or static_constants::CONSTANT_v (not constexpr) (if possible)
>>
>> What is your opinion? Are there still errors in it?
>>
>> It would be even nicer if boost::lexical_cast and/or boost::math::tools::convert_from_string were constexpr. This would further simplify the implementation.
>>
>> thx + regards
>> Gero
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

>> <config_more.hpp><cstdfloat_types_more.hpp><constants_more.hpp><OpenPGP_signature.sig>
> 
> 
> Gero,
> 
> As John and I have said before we are aware that C++23 fixed width floating point types will break Boost.Math. We have a type promotion system for built-in types that will fail because we do not have any code paths for those types yet. GCC 13 will be released in the next month or two and then we can throughly test and fix these issues.
> 
But I had already pointed out some time ago (when it was clear that there will be extended FP types) that there will probably be problems with boost. My request to prepare boost for this was unfortunately not followed.
> For the constants lexical_cast is almost never used. If we are operating with arbitrary precision arithmetic typically the types have string/char* constructors, (e.g. GMP, Boost.Multiprecision, etc.) so lexical_cast is not needed. You would also likely end up having to calculate the constant at runtime which we support (see boost/math/constants/calculate_constants.hpp). If you would like you can open a PR with your changes on our GitHub. Without the tests being run it is hard to tell if there are errors outside of the obvious.
> 
For the Boost.Multiprecision.* types, the constants cannot be represented constexpr - which ultimately reverts the calculation to lexical_cast or type-specific conversions. Probably you could make the Boost.Multiprecision.cpp_* types constexpr (which would be timely) and thus also a conversion string->float (in lexical_cast/convert_from_string/calculate_constants, the types themselves (constructor, assign, ...), etc).
However, I think you should replace/rename BOOST_DEFINE_MATH_CONSTANT with my BOOST_MAKE_MATH_CONSTANT (if error-free), so that it works for now.
> Matt