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
I think #2007 or #1135 broke the Number::toString abstract operation, now specifying a mathematical value equality where originally a floating point ("Number value") equality was meant.
Otherwise, let n, k, and s be integers such that k ≥ 1, 10k−1 ≤ s < 10k, s × 10n - k is ℝ(x), and k is as small as possible.
This sounds like s × 10n - k is a mathematical value, and to fulfill this equality exactly, s would need to be a quite long integer - no rounding permitted in choosing these values, and therefore no inaccuracy. This doesn't make sense to me in light of Note 1 ("The least significant digit of s is not always uniquely determined") and Note 2 ("For implementations that provide more accurate conversions […], choose the value of s for which s × 10n - k is closest in value to ℝ(x)").
I believe that instead this sentence should be
Otherwise, let n, k, and s be integers such that k ≥ 1, 10k−1 ≤ s < 10k, 𝔽(s × 10n - k) is x, and k is as small as possible.
and similiar for the more accurate version in Note 2
Otherwise, let n, k, and s be integers such that k ≥ 1, 10k−1 ≤ s < 10k, 𝔽(s × 10n - k) is x, and k is as small as possible. If there are multiple possibilities for s, choose the value of s for which s × 10n - k is closest in value to ℝ(x).
I think #2007 or #1135 broke the Number::toString abstract operation, now specifying a mathematical value equality where originally a floating point ("Number value") equality was meant.
In ES6, step 5 did still read as
At some point this changed to the current reading of
This sounds like
s × 10n - k
is a mathematical value, and to fulfill this equality exactly,s
would need to be a quite long integer - no rounding permitted in choosing these values, and therefore no inaccuracy. This doesn't make sense to me in light of Note 1 ("The least significant digit of s is not always uniquely determined") and Note 2 ("For implementations that provide more accurate conversions […], choose the value of s for whichs × 10n - k
is closest in value toℝ(x)
").I believe that instead this sentence should be
and similiar for the more accurate version in Note 2
For reference, this came up in answering the StackOverflow question Why does Number(“x”) == BigInt(“x”) … only sometimes?.
The text was updated successfully, but these errors were encountered: