CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 113
Normative: Increase limits on Intl MV and explicitly limit significant digits #1022
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
base: main
Are you sure you want to change the base?
Conversation
Just a note on the significant digits truncation: this could technically change the behavior of numbers so close to the edge of a rounding boundary where the discriminator is at a position less than -10000; for example, If this is a problem (it might not be: 10000 digits is beyond all known use cases), it can be fixed by performing a bigger refactoring of the spec in order to avoid the spec-required double rounding, but actually it is easier to implement if the truncation happens during parsing. |
Could someone confirm that this approach would not cause any issues with implementations that rely on ICU4C or ICU4J? |
ICU4C (and ICU4J) have a similar representation as ICU4X but use |
@erights It was suggested that we bring this PR to TG3. Could it be added to an upcoming TG3 agenda? |
Kris?
β¦On Thu, Aug 14, 2025 at 8:55β―PM Shane F. Carr ***@***.***> wrote:
*sffc* left a comment (tc39/ecma402#1022)
<#1022 (comment)>
@erights <https://github.com/erights> It was suggested that we bring this
PR to TG3. Could it be added to an upcoming TG3 agenda?
β
Reply to this email directly, view it on GitHub
<#1022 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACC3THL6LFDUYKUITH7ZGL3NVK4DAVCNFSM6AAAAACDPLFRVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJQGUZTGMBTHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Cheers,
--MarkM
|
TG2 conditional approval; we will defer to TG1 on exactly what bounds to use: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-09-11.md#normative-increase-limits-on-intl-mv-and-explicitly-limit-significant-digits-1022 |
1. If _rounded_ is *+β*<sub>π½</sub>, return ~positive-infinity~. | ||
1. If _rounded_ is *+0*<sub>π½</sub> and _intlMV_ < 0, return ~negative-zero~. | ||
1. If _rounded_ is *+0*<sub>π½</sub>, return 0. | ||
1. Let _e_ be the integer such that 10<sup>_e_</sup> β€ abs(_intlMV_) < 10<sup>_e_ + 1</sup>. |
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.
Choosing such an e is impossible if intlMV is zero. To fix it, handle the zero case separately.
The description above doesn't match what the algorithm is doing. I assume this is due to typos in the description? I don't see why 10e9999 would be in-bounds while 1e10000 would be out of bounds (it's the same mathematical value), which is what the description above is currently stating. The algorithm changes look good, once the bug when intlMV is zero is fixed. |
See #1017
The intent of this PR is the following. In this table,
99~9
stands in for 9999 digit 9s, and999~9
stands in for 10000 digit 9s.