Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P1467 Extended floating-point types and standard names #227

Open
jensmaurer opened this issue Jan 26, 2019 · 17 comments
Open

P1467 Extended floating-point types and standard names #227

jensmaurer opened this issue Jan 26, 2019 · 17 comments

Comments

@jensmaurer
Copy link
Member

@jensmaurer jensmaurer commented Jan 26, 2019

P1467R0 Extended floating-point types (Michał Dominiak, David Olsen)

@Lawrence-Crowl
Copy link

@Lawrence-Crowl Lawrence-Crowl commented Feb 20, 2019

SG6: Define narrowing conversions on rank instead of finite value ranges?
SF 2 F 3 N 1 A 0 SA 0

Make rank of overlapped ranges unordered.
SF 2 F 3 N 1 A 0 SA 0

Make operations on unordered ranks ill-formed.
SF 3 F 3 N 0 A 0 SA 0

@jfbastien
Copy link
Collaborator

@jfbastien jfbastien commented Feb 24, 2019

Lots of feedback in EWG-I in Kona. Want to see again. LEWGI should see this too.

@jfbastien jfbastien removed this from the 2019-02 milestone Feb 24, 2019
@jfbastien jfbastien added this to the 2019-07 milestone Feb 24, 2019
@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jun 23, 2019

P1467R1 Extended floating-point types (Michał Dominiak, David Olsen)

@jensmaurer jensmaurer added this to Tuesday in EWG-I in Cologne 2019 Jul 11, 2019
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Jul 16, 2019

Cologne 2019-07 LEWGI Minutes

P1467R1 Extended Floating Point Types: Design Review

Champion: Michał Dominiak

Minute Taker: Jayesh Badwaik

Start Overview: 07-16 10:42

Start Review: 11:02

Make sure outputting extended floating point types with iostreams works.

Is a type trait needed for determining floating-point conversion rank? Do we need any new type traits for floating point types in this brave new world?

Put the num_put/num_get ABI breaks on Titus' list of ABI breaks.

Cologne 2019-07 LEWGI Minutes

P1468R1 Fixed-Layout Floating Point Type Aliases: Design Review

Champion: Michał Dominiak

Minute Taker: Jayesh ?

Start Overview: 07-16 11:38

Start Review: 11:42

Start Polling: 11:48

POLL: Fixed-type floating point types are allowed to alias float, double, and long double.

Strongly For Weakly For Neutral Weakly Against Strongly Against
4 13 4 1 0

Attendance: 26

This has strong consensus.

POLL: Have the fixed-layout floating point types only be declared if they are available, and have feature test macros for each type.

NO OBJECTION TO UNANIMOUS CONSENT.

Attendance: 25

POLL: Forward P1467R0 (with the addition of support for extended floating point types in <atomic> and <random>) and P1468R0 to LEWG for C++23.

Strongly For Weakly For Neutral Weakly Against Strongly Against
2 15 5 1 0

A: Want to see more implementation experience.

Attendance: 25

End: 12:04

CONSENSUS: Forward P1467R0 (with the addition of support for extended floating point types in <atomic> and <random>) and P1468R0 to LEWG for C++23.

@jfbastien
Copy link
Collaborator

@jfbastien jfbastien commented Jul 18, 2019

EWGI in Cologne (seen with #228):

The extended floating-point types should be allowed to alias float/double/long double.
SF F N A SA
1 2 2 4 3
Forward the papers to EWG + LEWG.
SF F N A SA
3 9 0 0 0

Note one of the above polls reverse a LEWGI poll.

Send to EWG + LEWG.

@jensmaurer jensmaurer removed this from the 2019-07 milestone Aug 23, 2019
@jensmaurer jensmaurer added this to the 2019-11 milestone Aug 23, 2019
@jfbastien
Copy link
Collaborator

@jfbastien jfbastien commented Nov 7, 2019

EWG saw P1467 and P1468 at the same time.
http://wiki.edg.com/bin/view/Wg21belfast/P1467-EWG
http://wiki.edg.com/bin/view/Wg21belfast/P1468-EWG

  1. Allow (lossy) implicit conversion for the new extended floating-point types from larger to smaller
SF F N A SA
2 3 5 7 0
  1. Should floating-point aliases be optional?
SF F N A SA
4 5 2 3 1
  1. Assuming types aren’t optional, should we mandate using std::float32_t = float; using float64_t = double;
SF F N A SA
0 1 3 1 8
  1. Assuming types aren’t optional, should we mandate using std::float128_t = long double;
SF F N A SA
0 0 3 0 10
  1. Assuming aliasing double isn’t mandated, should std::float_t and others be allowed to alias double and others?
SF F N A SA
2 2 3 3 3
  1. EWG would like to see P1467 and P1468 again?
SF F N A SA
7 10 2 1 0

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jan 18, 2020

P1467R3 Extended floating-point types (David Olsen, Michał Dominiak)

@wg21bot wg21bot removed this from the 2019-11 milestone Jan 18, 2020
@wg21bot wg21bot added this to the 2020-02 milestone Jan 18, 2020
@jfbastien jfbastien added this to Unscheduled in EWG Prague Jan 22, 2020
@jfbastien jfbastien moved this from Unscheduled to Tuesday in EWG Prague Jan 23, 2020
@tituswinters tituswinters removed the LEWG label Jan 29, 2020
@tituswinters
Copy link
Collaborator

@tituswinters tituswinters commented Jan 29, 2020

These are going to EWG before LEWG, dropping the LEWG label.

@jfbastien
Copy link
Collaborator

@jfbastien jfbastien commented Feb 11, 2020

EWG in Prague saw this Tuesday afternoon with P1468 (#228).

EWG in Prague saw this Tuesday afternoon with P1467 (#227).

The new floatX_t types aren’t aliases for float / double / long double, they are independent types.

SF F N A SA
23 13 0 2 0

Allow implicit conversion between floatX_t* and float* / double* / long double* (i.e. pointers to the basic types) as a transition tool, only when they are representation compatible.

SF F N A SA
0 4 7 18 8

Extended floating point types match the current C++ rules for conversions.

SF F N A SA
2 3 6 19 3

Implicit conversions are only allowed if non-narrowing.

SF F N A SA
14 15 8 0 1

Don’t do anything implicitly (as opposed to matching the current C++ rules or tuning them).

SF F N A SA
2 7 6 14 4

Prefer smaller safe conversions over larger safe conversions in overload resolution.

SF F N A SA
3 14 10 0 7

Only add float16_t and bfloat16_t, don’t add float32_t / float64_t / float128_t.

SF F N A SA
0 5 17 10 3

@jensmaurer jensmaurer removed this from the 2020-02 milestone Feb 18, 2020
@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jun 17, 2020

P1467R4 Extended floating-point types and standard names (David Olsen, Michał Dominiak)

@wg21bot wg21bot added this to the 2020-telecon milestone Jun 17, 2020
@jfbastien jfbastien changed the title P1467 Extended floating-point types P1467 Extended floating-point types and standard names Jun 19, 2020
@jfbastien
Copy link
Collaborator

@jfbastien jfbastien commented Jun 19, 2020

P1468 was merged into this one, see #228 for its history.

@jfbastien
Copy link
Collaborator

@jfbastien jfbastien commented Jun 24, 2020

EWG telecon today:

Prefer smaller safe conversions over larger safe conversions in overload resolution (proposal in the paper, polled in Prague).

SF F N A SA
0 8 3 4 1

Overload resolution should stay the same, two different safe conversions should remain ambiguous (keep the current status-quo).

SF F N A SA
5 4 3 4 1

Adding back LEWG since the above is our last big unresolved Language question, and Library can operate without it being fully resolved (since they'll provide precise overloads regardless of what we go for).

@jfbastien jfbastien added the LEWG label Jun 24, 2020
@brycelelbach brycelelbach added this to 2020-08-04 Telecon in Library Evolution Telecons Jun 29, 2020
@brycelelbach brycelelbach moved this from 2020-08-04 to 2020-08-10 in Library Evolution Telecons Jul 27, 2020
@ben-craig
Copy link
Collaborator

@ben-craig ben-craig commented Aug 15, 2020

P1467R4: Extended floating-point types and standard names

P1467R4: Extended floating-point types and standard names

2020-08-10 Library Evolution Telecon Minutes

Chair: Ben Craig

Champion: David Olsen

Minute Taker: Mark Hoemmen, Guy Davidson

Start: 2020-08-10 10:00AM Central Daylight Time (US)

End: 11:30AM

SUMMARY:
Do research, incorporate feedback, and come back with another revision.

The chair recommends determining and reporting on the limitations of iostreams with extended floating point type. For example, can using the existing virtual methods for double provide satisfactory results?

Math functions with extreme precision can be very difficult to implement, so be sure to have an implementation in hand before we merge this.

The chair recommends listing prior work in the field that this is standardizing.

OUTCOME:
POLL: Require printing and formatting functions as part of this paper.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
2 4 5 3 2

Attendance: 21

# of Authors: 1

Author Position: N

Outcome:
No consensus. More implementation / field experience is a potential way to increase consensus.

@AaronBallman
Copy link
Collaborator

@AaronBallman AaronBallman commented Sep 15, 2021

Adding to the SG22 plate for naming and header file discussions related to the types coming from TS 18661 in WG14.

@AaronBallman
Copy link
Collaborator

@AaronBallman AaronBallman commented Oct 7, 2021

This was at the Oct 6, 2021 special SG22 session.

POLL: Should the usual arithmetic conversions in C++ follow the rules in C?

Committee SF F N A SA Notes
WG14 0 6 0 0 0 Consensus
WG21 2 3 2 2 0 Weak consensus, Authors were 1:F, 2:N

Consensus. Weak on the WG21 side.

POLL: Should the C implicit conversion rules change to follow the rules as proposed for C++?

Committee SF F N A SA Notes
WG14 0 0 0 2 2 No consensus
WG21 2 5 0 2 0 Consensus, Authors were 2:F, 1:A

No consensus.

POLL: Should the _Float* C names be available (through some means) in C++ and be used as the types behind the std::float* aliases?

Committee SF F N A SA Notes
WG14 5 1 0 0 0 Consensus
WG21 2 2 3 0 2 Weak consensus, Authors were 1:F, 2:N

SA vote rationale: My reasons against were that similar but slightly incompatible types is not good for the same names. My recommendation to Microsoft would be against. For the French national body, I can bring the issue to them.

Very weak consensus.

POLL: Use the std::floatN as opposed to std::floatN_t for aliases?

Committee SF F N A SA Notes
WG14 2 3 0 0 0 Consensus
WG21 2 2 1 3 1 No consensus, Authors were 3:A

SA vote rationale: Similar reasoning for the previous poll. Should there be an alias at all?

No consensus.

Removing from the SG22 plate.

@AaronBallman AaronBallman removed the SG22 label Oct 7, 2021
@erichkeane
Copy link
Collaborator

@erichkeane erichkeane commented Oct 21, 2021

Discussed at the EWG Teleon on October 21, 2021

EWG approves the direction on overload resolution as presented in D1467R6.

SF F N A SA
3 7 3 0 0

Result: Consensus.
We intend to see this paper again once the wording is updated to include
references to C23's Annex F, and has been reviewed by a wording expert.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants