673765 - parseInt / Number.toString with radix 36

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Christian]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

As stated on MDN, parseInt and Number.toString supports a radix upto 36.

parseInt(Number.MAX_VALUE.toString(36), 36) == Number.MAX_VALUE

should result in true, but is does not.


Actual results:

result for the given expression is false


Expected results:

result for the given expression should be true

Comment 1

[Jason Orendorff [:jorendorff]]

Well, as far as I can tell, toString is returning the right value. parseInt isn't parsing it correctly. Is there a numerical analyst in the house?

$ ./js
js> parseInt(Number.MAX_VALUE.toString(36), 36)
1.7976931348623135e+308
js> Number.MAX_VALUE
1.7976931348623157e+308
js> Number.MAX_VALUE.toString(36)
"1a1e4vngaiku6scyil2a1vcbg6qvbzjfseu5nty6qyr6ft0fmxyr3nmwlm21axdq6ed914edar7zmc0m6nphl75ran22ulsb7gk2x0w8eh76j4mr2dvcv9tlpr9qo3ap6my00o4k4hhs2393945uo1rspbz2qhhhvhwp0k4z956e50710y4rp9wvby29lpsvd8xlurk"

$ python
>>> int(float.fromhex('1.fffffffffffff7p1023'))
179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368L
>>> int(float.fromhex('1.fffffffffffff7p1023')) == int("1a1e4vngaiku6scyil2a1vcbg6qvbzjfseu5nty6qyr6ft0fmxyr3nmwlm21axdq6ed914edar7zmc0m6nphl75ran22ulsb7gk2x0w8eh76j4mr2dvcv9tlpr9qo3ap6my00o4k4hhs2393945uo1rspbz2qhhhvhwp0k4z956e50710y4rp9wvby29lpsvd8xlurk", 36)
True

Comment 2

[Eddy Bruel [:ejpbruel]]

The algorithm we use to parse an integer N with base B from a string S is quite straightforward: Let N = 0. For each digit D in the S, multiply the N with B, then add the value of the D to N.

The problem here seems to be that when S is a string representing Number.MAX_VALUE, the exponent E+308 is 'flattened', so to speak, so that when we try to parse S using the algorithm above, we exceed the limit of integer precision, leading to inaccuracies in the result.

There is one exception to this: if B is 10 or a power of two, we use a fallback method that accurately computes N in case of precision overflow. As stated in ECMA 15.1.2.2, step 13, in all other cases the algorithm is allowed to give an implementation-dependent approximation to N. Since 36 is neither 10 or a power of 2, the perceived inaccuracy is actually standard-conformant behavior.

Comment 3

[Eddy Bruel [:ejpbruel]]

Based on the comment above, I'm voting to WONTFIX this bug. dmandelin, can you please confirm?

Comment 4

[David Mandelin [:dmandelin]]

(In reply to ejpbruel from comment #3)
> Based on the comment above, I'm voting to WONTFIX this bug. dmandelin, can
> you please confirm?

Your analysis looks right to me. Other browsers do different things (Infinity as the output of the |parseInt(...)| is the most common), but none returns true for the equality test.