Date: Thu, 28 Aug 2025 20:06:58 +0000
I would like to point out how unnatural the sentence
"32-bit doubles are, however, more useful on these small microcontrollers"
as if that couldn't just be called a float.
I'm not saying it's a bad take, it's a view that has been around since CPUs have been designed.
Names don't mean anything, they can just be whatever, to the point that we can not clearly express exactly what we mean when we say "double" in a language that we use to program.
This is how people have been doing things for a very long time, but this is not normal.
Hence why I think float64_t does wonders in pinning down exactly what we mean.
This is not to say that there is no place for wishy-washy types in the standard, some algorithms don't require a specific type of float and the ability to just get "whatever the hardware happens to support" should be expressible.
But there should be an underlying layer of type names that express exactly what you get and then the stuff that can just be whatever should just be an alias of something deterministically expressed, and the names of those types should be reflective of the expectations required of those types.
I'm starting to believe that there should be a work group dedicated to add hardware specific content to the standard.
I.e. each cpu architecture should have a library available only to that architecture that allows a user do whatever is possible in that architecture.
And then have the rest of the portable standard re-use the arch specific components to implement it.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of David Brown via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, August 28, 2025 9:30:56 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: David Brown <david.brown_at_[hidden]>
Subject: Re: [std-proposals] TBAA and extended floating-point types
On 28/08/2025 18:41, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 28 August 2025 00:14:07 Pacific Daylight Time David Brown via Std-
> Proposals wrote:
>> With 32-bit doubles, the compiler is not standards conforming
>
> In what way?
>
> The C and C++ Standards do not require double to have a better precision than
> float. See https://cigix.me/c17#E.p4.
>
>
The range for doubles can be the same (DBL_MAX need only be 1e37, the
same as FLT_MAX), but the precision has to be greater (DBL_DIG must be
at least 10, requiring about 30 or so bits for the mantissa, and
DBL_EPSILON must be 1e-9 or smaller).
Doubles don't have to be 64-bit to be conforming - I think you can get
away with about 48 bits, but I am not an expert on the matter.
Doubles don't have to be better than floats - /if/ you have floats that
satisfy the requirements for doubles. So 64-bit floats and doubles is
fine, but 32-bit doubles are not.
32-bit doubles are, however, more useful on these small microcontrollers
in practice - you are not going to get far with 64-bit software floating
point routines that take up all the flash code space for many devices!
"32-bit doubles are, however, more useful on these small microcontrollers"
as if that couldn't just be called a float.
I'm not saying it's a bad take, it's a view that has been around since CPUs have been designed.
Names don't mean anything, they can just be whatever, to the point that we can not clearly express exactly what we mean when we say "double" in a language that we use to program.
This is how people have been doing things for a very long time, but this is not normal.
Hence why I think float64_t does wonders in pinning down exactly what we mean.
This is not to say that there is no place for wishy-washy types in the standard, some algorithms don't require a specific type of float and the ability to just get "whatever the hardware happens to support" should be expressible.
But there should be an underlying layer of type names that express exactly what you get and then the stuff that can just be whatever should just be an alias of something deterministically expressed, and the names of those types should be reflective of the expectations required of those types.
I'm starting to believe that there should be a work group dedicated to add hardware specific content to the standard.
I.e. each cpu architecture should have a library available only to that architecture that allows a user do whatever is possible in that architecture.
And then have the rest of the portable standard re-use the arch specific components to implement it.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of David Brown via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, August 28, 2025 9:30:56 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: David Brown <david.brown_at_[hidden]>
Subject: Re: [std-proposals] TBAA and extended floating-point types
On 28/08/2025 18:41, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 28 August 2025 00:14:07 Pacific Daylight Time David Brown via Std-
> Proposals wrote:
>> With 32-bit doubles, the compiler is not standards conforming
>
> In what way?
>
> The C and C++ Standards do not require double to have a better precision than
> float. See https://cigix.me/c17#E.p4.
>
>
The range for doubles can be the same (DBL_MAX need only be 1e37, the
same as FLT_MAX), but the precision has to be greater (DBL_DIG must be
at least 10, requiring about 30 or so bits for the mantissa, and
DBL_EPSILON must be 1e-9 or smaller).
Doubles don't have to be 64-bit to be conforming - I think you can get
away with about 48 bits, but I am not an expert on the matter.
Doubles don't have to be better than floats - /if/ you have floats that
satisfy the requirements for doubles. So 64-bit floats and doubles is
fine, but 32-bit doubles are not.
32-bit doubles are, however, more useful on these small microcontrollers
in practice - you are not going to get far with 64-bit software floating
point routines that take up all the flash code space for many devices!
-- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-08-28 20:07:01