P3008 R2 Atomic floating-point min/max

wg21bot commented 11 months ago

P3008R0 Atomic floating-point min/max (Gonzalo Brito Gadeschi)

cor3ntin commented 11 months ago

@ogiroux , @mattkretz - can SG1 and SG6 please review and tag LEWG once forwarded

ogiroux commented 10 months ago

SG1 poll in Kona:

DIRECTION POLL:
1. The default fetch_min(T, mo=SC)->T, fetch_max(T, mo=SC)->T should exist
2. The default fetch_min, fetch_max should have these semantics:
  * Which value is stored in the atomic is unspecified if an input is a NaN
  * Implementations should treat -0 as less than +0 (use normative encouragement)
  * (Note: must _not_ require std::min/max)
3. Users need a way to specify semantics (up to LEWG how to achieve this):
  * Must-have: fminimum/fmaximum
  * Must-have: fminimum_num/fmaximum_num
  * Can have if LEWG desires it but we do not: std::min/max
SF F N A SA
 5 6 2 0 0
Unanimous consent

inbal2l commented 7 months ago

Needs to be rebased on P0493. (Resolves issues, see #866)

wg21bot commented 7 months ago

P3008R1 Atomic floating-point min/max (Gonzalo Brito Gadeschi, David Sankel)

mattkretz commented 6 months ago

2024-03-19 SG6 (Numerics) Tokyo Meeting

P3008R1: Atomic floating-point min/max

2024-03-19 SG6 Minutes

Chair: Lisa Lippincott

Champion: Gonzalo Brito

Polls

POLL: Accept SG1 proposal as listed in P3008R1 with "implementation-defined" instead of "unspecified" and forward to LEWG.

SF	F	N	A	SA
2	3	2	2	0

# of Authors: 2 Outcome: Consensus Comments: Against because of a preference for only two function instead of three. Against because of a worry about implementation-defined.

Discussion about walking back from "implementation-defined". Take the above poll with a grain of salt in light of:

POLL: If one of the inputs is a NaN then it is "unspecified" whether the result value is either a NaN or the other value.

SF	F	N	A	SA
2	2	3	0	1

# of Authors: 2 Outcome: Consensus Comments: SA: bad for teachability

Discussion about -0 / +0. Status quo is still normative encouragement (as in the paper). No taste for a poll to change the status quo.

POLL: With respect to signaling NaNs, SG6 recommends:

for fetch_fminimum/fminimum_num/fmaximum/fmaximum_num to be specified in terms of their corresponding C23 APIs (ignore signaling NaNs in the wording, refer to C23), and
for fetch_min/max, to not explicitly specify signaling NaN behavior (ignore signaling NaNs in the wording)

SF	F	N	A	SA
4	3	2	0

# of Authors: 2 Outcome: Consensus

wg21bot commented 5 months ago

P3008R2 Atomic floating-point min/max (Gonzalo Brito Gadeschi, David Sankel)

gonzalobg commented 2 months ago

@inbal2l this is missing from LEWG agenda for St. Louis.

inbal2l commented 2 months ago

Hi @gonzalobg :) As a rule, not everything that is ready for LEWG can be seen in St. Louis (or during the next in-person meeting, for that matter), we usually prioritize large/urgent proposals and aim for the smaller ones However, I added it to our "Overflow" queue.

gonzalobg commented 2 months ago

Sorry, didn't want to imply that it must be seen; just wanted to make sure that if it wasn't, that that was intentional and not an oversight, since this paper was not part of the last mailing, but rather the post-Tokyo one, and is missing the "ready to be seen" label :(

Thank you Inbal!

inbal2l commented 1 month ago

2024-06-28 Library Evolution St. Louis Meeting

P3008R2: Atomic floating-point min/max

2024-06-28 Library Evolution St. Louis Minutes

Champion: Gonzalo Britto Chair: Inbal Levi & Fabio Fracassi Minute Taker: Eddie Nolan

Summary

POLL: Forward P3008R2 to LWG for C++26 to be confirmed by a Library Evolution electronic poll classified as B2 (fix).

SF	WF	N	WA	SA
10	7	0	0	0

Attendance: 20 IP + 4 R # of Authors: 2 Author Position: 1x SF 1x F Outcome: Unanimous consent

Next Steps

P3008R2 was forwarded to LWG for C++26 as B2 (fix) (to be confirmed by an LEWG electronic poll).

cplusplus / papers