Closed
Bug 673765
Opened 13 years ago
Closed 13 years ago
parseInt / Number.toString with radix 36
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: admin, Assigned: ejpbruel)
Details
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
Updated•13 years ago
|
Whiteboard: [mentor=jorendorff]
Comment 1•13 years ago
|
||
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
Updated•13 years ago
|
Whiteboard: [mentor=jorendorff]
Assignee | ||
Updated•13 years ago
|
Assignee: general → ejpbruel
Assignee | ||
Comment 2•13 years ago
|
||
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.
Assignee | ||
Comment 3•13 years ago
|
||
Based on the comment above, I'm voting to WONTFIX this bug. dmandelin, can you please confirm?
Comment 4•13 years ago
|
||
(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.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•