type detection macros + multiprecision + io

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

type detection macros + multiprecision + io

Boost - Dev mailing list
Hello Developer,
I noticed that some type detection macros and boost::float128_type or numeric_limits do not work reliably:
- BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok
- BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE or BOOST_NO_TYPE should be defined; see later
- with clang there is no boost::float128_type and an error when including boost/multiprecision/float128.hpp (quadmath.h)
- with clang and icc the numeric_limits<float128_t> are not available (gcc ok)
see https://godbolt.org/z/95PfTG

In general it would make sense:
- convert the detection macros to a uniform naming scheme:
  always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not mixed/both
- in multiprecision and math:
  1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d: decimal)
  2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked)
  3) based on this, renaming boost::float/int128_type to boost::float/int128_t
  so that it is always clear and there is no confusion.

You can do that for all types, e.g. some DSP/microcontrollers do not support u/int8/64_t etc. I did that quickly for gcc (has_type.hpp) - of course that has to be in the corresponding boost/config/compiler/* and platform/* headers are implemented.
Building on this, feature test macros can then be made available (features.hpp).

Can you please implement the io-operators and string-conversions for u/int128 (in e.g. boost/math/cstdint/cstdint_iostream.hpp)?

thx and regards
Gero


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

features.hpp (2K) Download Attachment
has_type.hpp (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: type detection macros + multiprecision + io

Boost - Dev mailing list
Am 07.09.20 um 00:00 schrieb Gero Peterhoff via Boost:
> Hello Developer,
> I noticed that some type detection macros and boost::float128_type or numeric_limits do not work reliably:
> - BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok
Is there an issue already open? If not can you open one (and a PR if
possible)?
> - BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE or BOOST_NO_TYPE should be defined; see later
This is a feature request, isn't it? So no char32/16_t detection exists
yet? Just making sure as you wrote "do not work reliably"
> - with clang there is no boost::float128_type and an error when including boost/multiprecision/float128.hpp (quadmath.h)
> - with clang and icc the numeric_limits<float128_t> are not available (gcc ok)
> see https://godbolt.org/z/95PfTG
Both of those are perfectly expected and a result of your first point.
At least if "do not work" means "are not defined when they should be".
Is that what you meant?
> In general it would make sense:
> - convert the detection macros to a uniform naming scheme:
>    always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not mixed/both
The types are spelled "float128" and "char32_t". Hence the macros are
spelled "HAS_FLOAT128" and "HAS_CHAR32_T". It is always "BOOST_HAS_<type
name>". Or did you see something different?
> - in multiprecision and math:
>    1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d: decimal)
>    2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked)
>    3) based on this, renaming boost::float/int128_type to boost::float/int128_t
>    so that it is always clear and there is no confusion.
Careful here. The C++ std went with a "_t" suffix for typedefs. So I'd
keep that. Can you clarify what you would rename exactly and why?
Adding an alias for boost::float128_t to the existing type makes sense IMO.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: type detection macros + multiprecision + io

Boost - Dev mailing list
On 2020-09-07 10:44, Alexander Grund via Boost wrote:

> Am 07.09.20 um 00:00 schrieb Gero Peterhoff via Boost:
>> - in multiprecision and math:
>>    1) float: renaming typenames to eg floatBits_mbt (m:
>> multiprecision, b: binary); floatBits_mdt (d: decimal)
>>    2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct
>> (c: checked)
>>    3) based on this, renaming boost::float/int128_type to
>> boost::float/int128_t
>>    so that it is always clear and there is no confusion.
> Careful here. The C++ std went with a "_t" suffix for typedefs. So I'd
> keep that. Can you clarify what you would rename exactly and why?
> Adding an alias for boost::float128_t to the existing type makes sense IMO.

I think float128_type and int128_type are deliberately named as such to
not reserve the _t names, which can later be used by the standard.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: type detection macros + multiprecision + io

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


> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Gero Peterhoff via Boost
> Sent: 6 September 2020 23:01
> To: [hidden email]
> Cc: Gero Peterhoff <[hidden email]>
> Subject: [boost] type detection macros + multiprecision + io
>
> Hello Developer,
> I noticed that some type detection macros and boost::float128_type or numeric_limits do not work
> reliably:
> - BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok
> - BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE
> or BOOST_NO_TYPE should be defined; see later
> - with clang there is no boost::float128_type and an error when including
> boost/multiprecision/float128.hpp (quadmath.h)
> - with clang and icc the numeric_limits<float128_t> are not available (gcc ok) see
> https://godbolt.org/z/95PfTG
>
> In general it would make sense:
> - convert the detection macros to a uniform naming scheme:
>   always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not
> mixed/both
> - in multiprecision and math:
>   1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d:
> decimal)
>   2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked)
>   3) based on this, renaming boost::float/int128_type to boost::float/int128_t
>   so that it is always clear and there is no confusion.
>
> You can do that for all types, e.g. some DSP/microcontrollers do not support u/int8/64_t etc. I did that
> quickly for gcc (has_type.hpp) - of course that has to be in the corresponding boost/config/compiler/*
> and platform/* headers are implemented.
> Building on this, feature test macros can then be made available (features.hpp).
>
> Can you please implement the io-operators and string-conversions for u/int128 (in e.g.
> boost/math/cstdint/cstdint_iostream.hpp)?

I think that BOOST_HAS_FLOAT128 Is telling the truth - it does not work for Clang and Intel ☹ (but does for GCC 😊)

On float128 support, we discussed some progress on https://github.com/boostorg/math/issues/181 but I have yet to get this to work on Windows Mingw and Clang 9.
It would be good to hear if others have made more progress (you report an unspecified error).

If you want to use 128-bit float, you can always use the Boost.Multiprecision cpp_bin_float_quad type, but it is slower of course than the hand-crafted assembler in quadmath.h.

It is possible to use the macro BOOST_HAS_FLOAT128 To use float128 when available else cpp_bin_float_quad so you can make it 'compiler portable' for now.

IO Operators and string convertors would indeed be nice. Code most welcome 😉

I am sure the @jzmaddock, custodian of Boost config will comment on the other suggestions.

HTH

Paul




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: type detection macros + multiprecision + io

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

On 06/09/2020 23:00, Gero Peterhoff via Boost wrote:
> Hello Developer,
> I noticed that some type detection macros and boost::float128_type or numeric_limits do not work reliably:
> - BOOST_HAS_FLOAT128 with clang and icc do not work, gcc is ok

This is deliberate - now I admit I need to recheck with the latest clang
and Intel compiler versions - but last time I did check there were
enough features missing to warrant not setting the macro.

In fact clang will set that macro if <quadmath.h> is present, the actual
detection logic is:

#if (defined(linux) || defined(__linux) || defined(__linux__) ||
defined(__GNU__) || defined(__GLIBC__)) && !defined(_CRAYC)
#if (__clang_major__ >= 4) && defined(__has_include)
#if __has_include(<quadmath.h>)
#  define BOOST_HAS_FLOAT128
#endif
#endif
#endif

Note that by default, quadmath.h is not present in clang's include path
which makes __float128 support next to useless.

> - BOOST_HAS_CHAR32/16_T, BOOST_NO_CHAR32/16_T are not defined, but either BOOST_HAS_TYPE or BOOST_NO_TYPE should be defined; see later
> - with clang there is no boost::float128_type and an error when including boost/multiprecision/float128.hpp (quadmath.h)
Correct, see above, please fix your include path to find quadmath.h
> - with clang and icc the numeric_limits<float128_t> are not available (gcc ok)
> see https://godbolt.org/z/95PfTG
>
> In general it would make sense:
> - convert the detection macros to a uniform naming scheme:
>    always BOOST_HAS_TYPE_T (with _T at the end) or BOOST_HAS_TYPE (without _T), but not mixed/both
> - in multiprecision and math:

No, you're mixing two different things, we always use BOOST_HAS_<name>,
and the names are either "float128" or "char16_t" etc, there is no
"float128_t" or "char16".

HTH, John.

>    1) float: renaming typenames to eg floatBits_mbt (m: multiprecision, b: binary); floatBits_mdt (d: decimal)
>    2) integer: renaming typenames to e.g. u/intBits_mt; u/intBits_mct (c: checked)
>    3) based on this, renaming boost::float/int128_type to boost::float/int128_t
>    so that it is always clear and there is no confusion.
>
> You can do that for all types, e.g. some DSP/microcontrollers do not support u/int8/64_t etc. I did that quickly for gcc (has_type.hpp) - of course that has to be in the corresponding boost/config/compiler/* and platform/* headers are implemented.
> Building on this, feature test macros can then be made available (features.hpp).
>
> Can you please implement the io-operators and string-conversions for u/int128 (in e.g. boost/math/cstdint/cstdint_iostream.hpp)?
>
> thx and regards
> Gero
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost