generalize boost macros

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

generalize boost macros

Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

pEpkey.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

pEpkey.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list

> 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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list

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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

pEpkey.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
In reply to this post by Boost - Users mailing list

> 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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: generalize boost macros

Boost - Users mailing list
>> 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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

pEpkey.asc (1K) Download Attachment