Hello, I have some ideas for config/predef, multiprecision and others. config/predef: What bothers me is the inconsistent nomenclature of several macros. For example, integer: BOOST_HAS_INT128 BOOST_NO_INT64_T float: BOOST_FLOATx_C decimal: ? I think you should definitely generalize that: BOOST_HW_TYPE_AVAILABLE: only if TYPE is supported by the hardware (based on BOOST_HW_SIMD*), but not necessarily by the compiler or selected architecture BOOST_LIB_TYPE_AVAILABLE: TYPE is available from the c++library/compiler For example, float80_t: has HW support on x86 (BOOST_HW_FLOAT80_AVAILABLE is defined), but not on MSVC (BOOST_LIB_FLOAT80_AVAILABLE is not defined then) BOOST_SW_TYPE_AVAILABLE: there is an external emulation of TYPE For example, multiprecision A's complement fixed precision integer (TODO) or "half" by sourceforge Of course, this must be set manually. At least for int/float/decimal 8..512 this should be available. BOOST_HW_MACHINE_SIZE: the real word size of HW BOOST_ARCH_MACHINE_SIZE: the word size of the architecture For example, DOS on AMD Ryzen BOOST_HW_MACHINE_SIZE = 64 and BOOST_ARCH_MACHINE_SIZE = 16 multiprecision/float128_t: there are still many features missing most values in numeric_limits<float128_t> are not constexpr math::constants: i miss log2(2/e/pi/10) etc and i miss BOOST_COMP_VECTOR_EXTENSIONS_AVAILABLE if the compiler supports __attribute__(__vector_size__(...)) and BOOST_COMP_VECTOR_EXTENDED_EXTENSIONS_AVAILABLE if the compiler supports extendet vector extensions (currently only clang/llvm?) and BOOST_ARTIFICIAL __attribute__((artificial)) if supported thx
multiprecision/float128_t:
there are still many features missing Specifically? most values in numeric_limits<float128_t> are not constexpr
I know :( There has been some work towards making the library constexpr throughout where possible: but I came to the conclusion that it wasn't possible without is_constant_evaluated() from C++20. numeric_limits<float128> might be possible though.
math::constants: i miss log2(2/e/pi/10) etc
Not sure I follow, do you really mean log2(2) ?? Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Am 01.02.19 um 22:08 schrieb John Maddock via Boost-users:
multiprecision/float128_t:
there are still many features missing Specifically? eg exp2, log2, logb, modf, round, scalbn, copysign, signbit, isnormal are not available in std:: for float128_t, see cstdfloat_cmath.hpp. I'd like a full float128_t feature set, see https://en.cppreference.com/w/cpp/numeric/math and https://en.cppreference.com/w/cpp/numeric/special_math. most values in numeric_limits<float128_t> are not constexpr
I know :(
There has been some work towards making the library constexpr throughout where possible: but I came to the conclusion that it wasn't possible without is_constant_evaluated() from C++20. numeric_limits<float128> might be possible though.
math::constants: i miss log2(2/e/pi/10) etc
Not sure I follow, do you really mean log2(2) ?? This is not constexpr for float128_t and the compiler generates a function call. :-(
Best, John.
Thank you very much Gero
This is not constexpr for float128_t and the compiler generates a function call. :-(
This works fine for me: #include <boost/cstdfloat.hpp> #include <boost/math/constants/constants.hpp> int main() { using boost::float128_t; constexpr float128_t pi = boost::math::constants::pi<float128_t>(); return 0; } --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Am 02.02.19 um 19:15 schrieb John Maddock via Boost-users:
This is not constexpr for float128_t and the compiler generates a function call. :-(
This works fine for me:
#include <boost/cstdfloat.hpp> #include <boost/math/constants/constants.hpp>
int main() { using boost::float128_t;
constexpr float128_t pi = boost::math::constants::pi<float128_t>();
return 0; }
That's exactly my problem. namespace std { // declare missing log2, cannot say constexpr: compilererror inline float128_t log2(const float128_t& arg) noexcept { return log2q(arg); } } // also not constexpr inline float128_t myfunc(const float128_t& arg) noexcept { // log2_e not available // constexpr float128_t factor = boost::math::constants::log2_e<float128_t>(); // compiler generates a function call to log2 const float128_t factor = std::log2(boost::math::constants::e<float128_t>()); return arg*factor; } thx Gero
That's exactly my problem.
namespace std { // declare missing log2, cannot say constexpr: compilererror inline float128_t log2(const float128_t& arg) noexcept { return log2q(arg); } }
There's no conceivable way we can implement that as a constexpr algorithm.
// also not constexpr inline float128_t myfunc(const float128_t& arg) noexcept { // log2_e not available // constexpr float128_t factor = boost::math::constants::log2_e<float128_t>();
// compiler generates a function call to log2 const float128_t factor = std::log2(boost::math::constants::e<float128_t>());
return arg*factor; }
log2(e) == 1/log(2) So: constexpr float128_t log2_e = 1 / boost::math::constants::ln_two<float128_t>(); does actually work just fine. Note that we cannot provide every single conceivable constant, so you can also define your own: namespace boost { namespace math { namespace constants { BOOST_DEFINE_MATH_CONSTANT(log2_e, 1.4426950408889634073599246810018921374266459541529859341, "1.4426950408889634073599246810018921374266459541529859341354494069311092191811850798855266228935063444969975183096"); } } } Which is also constepxr for float128_t. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
namespace std { inline float128_t log2(const float128_t& arg) noexcept { return log2q(arg); } }
There's no conceivable way we can implement that as a constexpr algorithm.
I know. But I think it is better to offer all functions than non-constexpr than not at all - the function set should always be complete. The functions available so far for float128_t are not constexpr. But back to the original topic. How do you think about unifying macros to detect available types (including vector extension) ? I have read in the TODO list of multiprecision that it is planned to offer real 2's complement big-integer (constexpr?). When can i expect it? PS: I think it's really bad that in the C/C++-standard there are still no mini-floats (float8_t), float16_t, float128_t and u/int128_t and bigger. :-( One persists on the completely outdated nomenclature as short, long int, long long int, long double, no distinction between u/char and u/int8_t (iostream) etc. :-( thx Gero
On 2/1/19 1:08 PM, John Maddock via Boost-users wrote:
There has been some work towards making the library constexpr throughout where possible: but I came to the conclusion that it wasn't possible without is_constant_evaluated() from C++20. numeric_limits<float128> might be possible though.
Hmm - I've heard that gcc already implements is_constant_evaluated(). Could be wrong though. In any case, the capability in the works for HAS_IS_CONSTANT_EVALUATED? or similar? I think I could benefit from it right now. Robert Ramey
On 02/02/2019 19:03, Robert Ramey via Boost-users wrote:
On 2/1/19 1:08 PM, John Maddock via Boost-users wrote:
There has been some work towards making the library constexpr throughout where possible: but I came to the conclusion that it wasn't possible without is_constant_evaluated() from C++20. numeric_limits<float128> might be possible though.
Hmm - I've heard that gcc already implements is_constant_evaluated(). Could be wrong though. In any case, the capability in the works for HAS_IS_CONSTANT_EVALUATED? or similar? I think I could benefit from it right now.
I don't think it's in any released gcc version, but they are busy making use of it in libstdc++ development I believe, so it's on it's way. I'm hoping most compiler vendors will make it available in pre-C++20 mode as well. Ah wait, it's scheduled for gcc-9: https://gcc.gnu.org/projects/cxx-status.html#cxx2a |__builtin_constant_p almost does what we need, but it's GCC only (clang supports it, but it doesn't do constexpr detection as it always returns the same value so far as I can tell).| |There are some suggested gadgets here: https://stackoverflow.com/questions/13299394/is-is-constexpr-possible-in-c11 which detect whether a function may be used in a constexpr context, but nothing that permits you to determine whether the current context is constexpr or not (one claim to the contrary not withstanding). | Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 2/2/19 11:37 AM, John Maddock via Boost-users wrote:
Hmm - I've heard that gcc already implements is_constant_evaluated(). Could be wrong though. In any case, the capability in the works for HAS_IS_CONSTANT_EVALUATED? or similar? I think I could benefit from it right now.
I don't think it's in any released gcc version, but they are busy making use of it in libstdc++ development I believe, so it's on it's way. I'm hoping most compiler vendors will make it available in pre-C++20 mode as well. Ah wait, it's scheduled for gcc-9: https://gcc.gnu.org/projects/cxx-status.html#cxx2a sounds promising.
|__builtin_constant_p almost does what we need, but it's GCC only (clang supports it, but it doesn't do constexpr detection as it always returns the same value so far as I can tell).| Damn - I was holding out hope for that.
|There are some suggested gadgets here: https://stackoverflow.com/questions/13299394/is-is-constexpr-possible-in-c11 which detect whether a function may be used in a constexpr context, but nothing that permits you to determine whether the current context is constexpr or not (one claim to the contrary not withstanding).
I looked at this carefully but wasn't convinced that it would do the job for me. My interest is to make safe_literal unnecessary. Robert Ramey
participants (3)
-
Gero Peterhoff -
John Maddock -
Robert Ramey