boostorg/math

Fixed-width floating-point C++23 and <cstdfloat.hpp>

ckormanyos opened this issue · 11 comments

ckormanyos commented

Hi John (@jzmaddock) and Matt (@mborland)

I've been pleasantly looking at fixed-width floating-point types for C++23. There was a recent update of an original idea from the past, which seems to have gotten enough traction to get into the lang.

Upon inspection of the wording, the link states

  • "... the fixed width floating-point types must be aliases to extended floating point types (not float / double / long double)."

In light of this, does it make sense (for those compilers supporting this feature) to change the detection mechanism for a compiler's having boost::float32_t, boost::float64_t, etc.? We used the presence of built-in types with the relevant digit counts for detection previously.

I wonder if this proposal means for C++23 and beyond that it's better to check for the presence of the extended types? I suppose on a practical level, it makes no difference whatsoever, but it would be formally correct under-the-hood?

Thoughts?

ckormanyos commented

I guess I'd wonder what (in C++23) should be the result of

?

// What's up here if C++ compiler supports C++23 float32_t?
std::assert(std::is_same<boost::float32_t, float>::value);
ckormanyos commented

There's maybe other questoins that'll arise like:

  • Interact how with <limits> / <complex>?
  • Do templates need to specifically target the range of std::float16_t now that it may become more prevalent?

And more stuff that might arise. Similar (but different) questions might arise for Multirpecision.

ckormanyos commented

I looked a little deeper, and this checkin is cool with provisions for <limits>, atomics, <type_traits>, std::abs(), etc.

jzmaddock commented

I see two issue here:

  • We should probably do what the std says (BTW I couldn't find any mention of in the working draft??) and use the C-language extension types in our cstdfloat.hpp when available (if we can tell).
  • We should start testing our code against _Float32 etc as well as float/double etc. Mostly just some concept checks would do here I hope, we don't really want to have to double the testing load :(
ckormanyos commented

That seems reasonable.

As for 16-bit, I don't have the strength at the moment to address the issue of float16_t and <cmath>/<complex>, neither in Boost nor with the committee in the std-draft.

ckormanyos commented

Should I close this issue John (@jzmaddock), or leave it hanging around for the future?

jzmaddock commented

float16_t is basically a storage type only, I can't imagine doing [complex] arithmetic with it. We should just update the logic in promote.hpp to promote it to "whatever" C++ does: float? Not sure if it's even specified?

Maybe leave this hanging around as a reminder for now?

mborland commented

Here is the section on conversion rank and promotion. Going by the typical rhythm for GCC late April is when we should see GCC 13 with support for these new types.

mborland commented

GCC-13 is now available on Ubuntu 23.04 and Fedora 38. This week I am going to investigate how these new types affect things.

jzmaddock commented

Thanks Matt, does this mean we can get gcc-13.1 CI working? If so enabling it for Boost.Config, and maybe setting up some macros for the new types might be the first order of business (and quick to do - CI cycles really fast on Config).

mborland commented

Thanks Matt, does this mean we can get gcc-13.1 CI working? If so enabling it for Boost.Config, and maybe setting up some macros for the new types might be the first order of business (and quick to do - CI cycles really fast on Config).

Not yet. The package is only available on 23.04 right now, and the latest version GHA has is 22.04.