Date: Tue, 26 Aug 2025 19:49:25 +0000
> On Mon, Aug 25, 2025, at 23:19, Paul Caprioli via Std-Proposals wrote:
> > Given std::vector<double> x(40);
> > suppose we allowed: std::span<std::float64_t, 40>(x);
> >
> > Philosophically, I want a non-owning view of the data, so maybe
> > std::span is a good choice?
> > I don't want actual conversion; I think I'd prefer compilation to fail.
> are we forcing that double and float64_t are both the same bit repreresentaiton?
If the std::span object above is constructible, then yes, double and float64_t have the same bit representation.
In general, double and float64_t may not have the same bit representation. If they do not, I'm proposing the code above not compile.
> There are many who want std::float64_t to be ieee-754, even if the hardware is different.
Yes, it is written in [basic.extended.fp] that std::float64_t is ieee-754 binary64:
If the implementation supports an extended floating-point type whose properties are specified by the ISO/IEC 60559 floating-point interchange format binary64, then the typedef-name std::float64_t is declared in the header <stdfloat> and names such a type, the macro __STDCPP_FLOAT64_T__ is defined, and the floating-point literal suffixes f64 and F64 are supported.
> I know ieee-754 is from 1985 and nearly everyone uses it and thus double is for paractial purposes ieee-754, but are we forcing that
No, we're not forcing that. (Takum arithmetic, for example, is interesting: https://www.arith2025.org/program.html)
The standard floating-point types (float, double, long double) are not required to be IEEE-754.
If however, e.g., double is IEEE-754 binary64, then I am looking for a way for my program that uses double to use a library written to use std::float64_t.
The scalars convert nicely. The struggle is with pointers.
> If floating point might be something else (either in the future, on maybe on esoteric hardware nobody in this discussion is aware of) then we need to figure out how casting works. Do we say static_cast will convert between the two, or make it a compiler error if the implementation doesn't use the same bit representatoin for both.
Yes, static_cast can convert between different floating-point types. For example, static_cast between float and double works and changes the bits.
> The second question is when the implementation knows the underlying bit representation is exactly the same do we allow aliasing.
There is push-back on allowing aliasing (i.e., on prohibiting TBAA optimizations based on double and std::float64_t being different types).
Unfortunately, I find myself agreeing. But I want to allow gradual adoption of std::float64_t, so I want a painless way to cast double* to std::float64_t* and back again.
This casting of pointers only needs to work if double is IEEE-754 binary64.
Maybe the magic can be hidden in a new constructor for std::span.
> -----Original message-----
> From: Sebastian Wittmeier <wittmeier_at_[hidden]>
> Sent: Monday, August 25 2025, 2:05 pm
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>;
> Paul Caprioli <paul_at_[hidden]>
> Subject: AW: [std-proposals] TBAA and extended floating-point types
>
> Perhaps we need bit_cast or other conversions for arrays and templated
> containers. Either as noop or as actual conversion.
>
> ranges? adapter classes? Do we have enough facilities?
>
> -----Ursprüngliche Nachricht-----
> Von: Paul Caprioli <paul_at_[hidden]>
> Gesendet: Mo 25.08.2025 22:03
> Betreff: RE: [std-proposals] TBAA and extended floating-point types
> An: std-proposals_at_[hidden];
> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>;
>> What about bitcast instead?
>
> I'm thinking about the following, and don't see how bitcast is useful:
>
> void daxpy(std::size_t n, const std::float64_t alpha, const std::float64_t* x,
> std::float64_t* y) {
> for (std::size_t i = 0; i < n; ++i) y[i] += alpha * x[i];
> }
>
> int main() {
> std::size_t n = 40;
> double alpha = 2.0;
> std::vector<double> x(n, 1.0);
> std::vector<double> y(n, 3.0);
>
> daxpy(n, alpha, x.data(), y.data());
>
> std::cout << y[17] << '\n'; // UB
> }
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-08-26 19:49:26