You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I changed part of the ToRawPrecision algorithm in ES2019 as part of Unified NumberFormat. However, in my work on NFv3, I realized that one change I made is unsound. This is in a crucial function, ToRawPrecision, which is used for all significant digits rounding.
Problem explanation: In ToRawPrecision, the e value is supposed to represent the power of 10 of the resolved number after rounding. However, my change in ES2020 computed e based on the input value before rounding.
Example values of x, p, n, and e, with xFinal for reference:
Formula: x ≈ n × 10e–p+1
x
p
n
e
xFinal
1.11
3
111
0
1.11
11.1
3
111
1
11.1
1.11
2
11
0
1.1
11.1
2
11
1
11
9.999
3
100
1
10.0
9.999
2
10
1
10
9.9
3
990
0
9.90
9.9
2
99
0
9.9
Practically, the ES2020 algorithm works in all cases except those where the number rounds up to the next magnitude. A spec-compliant ES2020 implementation would need to return "9.99" instead of "10.0" in the fifth row.
Please check my logic!
All browsers still implement it correctly, but I would like to restore the old algorithm as soon as possible. I consider this an editorial change because it is restoring correct behavior after a mess-up in ES2020. (2021-05-06: This is still normative.)
Can we sneak this into ES2021? (2021-05-06: No, don't push this into ES 2021.)
sffc
changed the title
Normative: Restore ES2019 algorithm for ToRawPrecision
Normative: Fix spec bugs in numberformat.html caused by Unified NumberFormat
May 12, 2021
The reason will be displayed to describe this comment to others. Learn more.
The PartitionNumberPattern revert looks great, the ToRawPrecision change is a bit more complicated but since it is exactly the same as the previous line, it should be all good.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I changed part of the ToRawPrecision algorithm in ES2019 as part of Unified NumberFormat. However, in my work on NFv3, I realized that one change I made is unsound. This is in a crucial function, ToRawPrecision, which is used for all significant digits rounding.
Problem explanation: In ToRawPrecision, the e value is supposed to represent the power of 10 of the resolved number after rounding. However, my change in ES2020 computed e based on the input value before rounding.
Example values of x, p, n, and e, with xFinal for reference:
Formula: x ≈ n × 10e–p+1
Practically, the ES2020 algorithm works in all cases except those where the number rounds up to the next magnitude. A spec-compliant ES2020 implementation would need to return "9.99" instead of "10.0" in the fifth row.
Please check my logic!
All browsers still implement it correctly, but I would like to restore the old algorithm as soon as possible.
I consider this an editorial change because it is restoring correct behavior after a mess-up in ES2020.(2021-05-06: This is still normative.)Can we sneak this into ES2021?(2021-05-06: No, don't push this into ES 2021.)