[cfp-interest 3453] Fwd: floating point

[Jim Thomas]

With Guy’s permission I’m forwarding this message about his C++ proposal titled “Reproducible floating-point results”. He’s interested in feedback from CFP. 

- Jim Thomas

> Begin forwarded message:
> 
> From: Guy Davidson <guy.cpp.wg21 at gmail.com>
> Subject: Re: floating point
> Date: April 17, 2025 at 8:52:28 AM PDT
> To: Jim Thomas <jaswthomas at sbcglobal.net>
…

> Hi Jim.
> 
> First of all, apologies for four months of radio silence. I am the chair of the ACCU conference and my home has been undergoing emergency remedial renovations over the past couple of months. My time has been rather soaked up by all this.
> 
> Robert has put you in contact with me because I am in the process of proposing new floating point behaviour for C++ (I've been on the committee for a decade now) and there was a suggestion that WG14 might be interested in this work. The proposal can be found at https://wg21.link/P3375. In summary, I want a method to ensure that floating point arithmetic is portable across implementations, producing the same results for the same operations. IEEE 574-2019 clause 11 describes this as reproducible floating point arithmetic. My employer has made this my top priority.
> 
> There are two approaches I can think of: one is to create correctly rounded functions, but my main concern is how code will interact with optimisations. Requiring users to carefully eliminate all floating point optimisations strikes me as non-ergonomic. The other approach is to create a new fundamental type that is defined according to IEEE 574 specs and is immune to optimisations. I prefer this approach since it is more ergonomic. Testing it out in gcc and clang will be non-trivial, but I'll cross that bridge when I come to it.
> 
> There is a third approach which is to simply introduce a new pragma directive, similar to those proposed by Joshua Cranmer and adopted recently by the C standard. This ran into trouble in the C++ committee as we are trying to avoid adding new pragma directives because of problems with the one definition rule and the minefields that are opened up if those pragmas are introduced conditionally to inline files.
> 
> I would welcome any input from you about this.
> Is this something that would interest the C committee (it is being greeted with great approval by other C++ committee members)?
> Is it a completely forlorn hope? (If so, why?)
> Is there a fourth approach you can think of?
> 
> I have more time than usual available to me over the next week or so, so if you would like to hop on a video call I would be delighted to make your acquaintance. I am also forming plans to attend the next WG14 committee in Brno in August.
> 
> Thank you for your time.
> Best regards,
> Guy Davidson
> Chair
> BSI IST/5
> 
> On Fri, 6 Dec 2024 at 15:26, Robert Seacord <rcseacord at gmail.com <mailto:rcseacord at gmail.com>> wrote:
>> Let me get you guys chatting directly so I'm not in the way.  :)
>> 
>> Thanks,
>> rCs
>> 
>> On Fri, Dec 6, 2024 at 10:23 AM Guy Davidson <guy.cpp.wg21 at gmail.com <mailto:guy.cpp.wg21 at gmail.com>> wrote:
>>> Thanks Robert
>>> 
>>> Joshua certainly seems knowledgeable. Thanks for your confirmation.
>>> 
>>> One of the problems we are having with pragmas is about how the preprocessor and modules interact. What would be preferred would be something that happens after the preprocessor.
>>> 
>>> void foo() {
>>>   if constexpr (std::fma_contract_is_supported()) {
>>>     std::fma_contract(true);
>>>     ...
>>>     std::fma_contract(false);
>>>   else {
>>>     ... different rounding behaviour
>>>   }
>>> }
>>> 
>>> Indeed, the wish in the numerics group is better control over the floating point environment at compile time and run time, since among other things we have a problem with the interpretation of literals. https://github.com/cplusplus/papers/issues/1584
>>> 
>>> However, since I wrote to you I have spoken with a compile-time expert (Hana Dusikova, chair of the WG21 reflection study group) who has further reservations about changing the compiler state during compilation. I am going to revisit my paper and perhaps limit my proposal to checking what is supported and what is set, rather than attempting to set a flag at compile time rather than preprocessor time.
>>> 
>>> All of this started up because I wrote a paper about reproducible floating point arithmetic (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3375r1.html), as described in clause 11 of IEEE 754:2019 (ISO/IEC 60559:2020). It is a keenly sought-after feature and I appear to have opened a giant can of worms. It seems the only solution to improving rounding and reproducibility are new families of core types, which is a big job.
>>> 
>>> Thanks for your consideration.
>>> 
>>> Cheers,
>>> G
>>> 
>>> On Fri, 6 Dec 2024 at 07:56, Robert Seacord <rcseacord at gmail.com <mailto:rcseacord at gmail.com>> wrote:
>>>> 
>>>> Guy, 
>>>> 
>>>> Here is some feedback from our floating point study group.
>>>>> 2. Floating-point
>>>>> At the WG21 committee last week Joshua Cranmer brought a paper about introducing some new floating-point pragmas to C++ from C. The paper is https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3479r0.html.
>>>> 
>>>> FYI, Joshua has been attending CFP meetings and seems knowledgeable. However, the C++ paper has not been discussed by CFP.
>>>> 
>>>>> 
>>>>> The committee wasn't keen on introducing more pragmas to the standard, and I wondered about constexpr/consteval functions instead. This would have the added benefit of compile time code path selection based on floating point facilities exposed by the implementation.
>>>> 
>>>> Hmm. Maybe I don’t understand what you’re suggesting. The floating-point pragmas give the user a way to select different semantics for the code in the scope of the pragma. Or as Joshua says in his paper, the pragmas "provide some means of local control over the floating-point model, without having to rely on compiler flags.” The determination of the semantics is done at compile time, but the determined semantics apply regardless of whether the code is executed at translation time or execution time. How could you use constexpr/consteval functions to provide the same functionality as a floating-point pragma? An example or two might help.
>>>> 
>>>> Thanks,
>>>> rCs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20250507/0c77e5bf/attachment.htm>