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

Am 01.02.19 um 22:08 schrieb John Maddock via Boost-users: 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 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

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 #include

int main() {    using boost::float128_t;

   constexpr float128_t pi = boost::math::constants::pi();

   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(); // compiler generates a function call to log2 const float128_t factor = std::log2(boost::math::constants::e()); return arg*factor; } thx Gero

...

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 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