-
Notifications
You must be signed in to change notification settings - Fork 107
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
Normative: Fix spec bugs in numberformat.html caused by Unified NumberFormat #572
Conversation
I found another spec bug originating from Unified NumberFormat, which I added to this PR as 565a054. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
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.
@gibson042 @leobalter could we have another review on this? |
I would like to have this checked in. Can I have another review please? |
2021-05-25: TG1 consensus at https://github.com/tc39/notes/blob/master/meetings/2021-05/may-25.md#ecma402-status-update. |
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
@sffc do you think this is ready to merge? |
Yes, if you all approve, this can be merged. Is there anything that needs to be done to fix the CI failure, or is that just flaky? |
It's unlikely to be flaky; if you rebase it i suspect you'll see a real lint failure. |
Update PR #572 with latest master
I merged in the latest master, and CI is green now. 😃 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, thanks, will all the boxes checked, let's merge this!
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.)