459,481 Members | 1,199 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,481 IT Pros & Developers. It's quick & easy.

# parseInt() question

 P: n/a Why does parseInt("0000000000000018") return 1, while parseInt("0000000000000018", 10) return 18? My assumption was that the base 10 would be default argument for radix. Wouldn't you want to get back 18 in most if not all cases? Any thoughts? -Thx Jun 17 '07 #1
12 Replies

 P: n/a wrote on 17 jun 2007 in comp.lang.javascript: Why does parseInt("0000000000000018") return 1, while parseInt("0000000000000018", 10) return 18? My assumption was that the base 10 would be default argument for radix. Your assumption is wrong, it is octal. Read the specs: parseInt(numString, [radix]) numString Required. A string to convert into a number. radix Optional. A value between 2 and 36 indicating the base of the number contained in numString. If not supplied, strings with a prefix of '0x' are considered hexadecimal and strings with a prefix of '0' are considered octal. All other strings are considered decimal. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) Jun 17 '07 #2

 P: n/a ki*******@gmail.com wrote: Why does parseInt("0000000000000018") return 1, while parseInt("0000000000000018", 10) return 18? My assumption was that the base 10 would be default argument for radix. Wouldn't you want to get back 18 in most if not all cases? There was a mistake made in the specification of parseInt. That is why you should always explicitly indicate the radix. Don't depend on the default being 10. As you demonstrated, it is not reliable. JSLint will read your source and identify the places where the default is missing. http://www.JSLint.com/ Jun 17 '07 #3

 P: n/a Evertjan. wrote: wrote on 17 jun 2007 in comp.lang.javascript: >Why does parseInt("0000000000000018") return 1, whileparseInt("0000000000000018", 10) return 18?My assumption was that the base 10 would be default argument forradix. Your assumption is wrong, it is octal. Read the specs: parseInt(numString, [radix]) numString Required. A string to convert into a number. radix Optional. A value between 2 and 36 indicating the base of the number contained in numString. If not supplied, strings with a prefix of '0x' are considered hexadecimal and strings with a prefix of '0' are considered octal. All other strings are considered decimal. I'd like to know where you read that from. The Core JavaScript 1.5 specifically states that, that behavior is deprecated. http://developer.mozilla.org/en/docs...nt#Description -- -Lost Remove the extra words to reply by e-mail. Don't e-mail me. I am kidding. No I am not. Jun 17 '07 #4

 P: n/a -Lost wrote on 17 jun 2007 in comp.lang.javascript: Evertjan. wrote: >radixOptional. A value between 2 and 36 indicating the base of the numbercontained in numString. If not supplied, strings with a prefix of'0x' are considered hexadecimal and strings with a prefix of '0' areconsidered octal. All other strings are considered decimal. I'd like to know where you read that from. MS The Core JavaScript 1.5 specifically states that, that behavior is deprecated. Could be that the behavior is deprecated, but it still seems to work that way. Do you sometimes feel deprecated and Lost forever too, dreadful sorry, Clementine? -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) Jun 17 '07 #5

 P: n/a Evertjan. wrote: -Lost wrote on 17 jun 2007 in comp.lang.javascript: >Evertjan. wrote: >>radixOptional. A value between 2 and 36 indicating the base of the numbercontained in numString. If not supplied, strings with a prefix of'0x' are considered hexadecimal and strings with a prefix of '0' areconsidered octal. All other strings are considered decimal. I'd like to know where you read that from. MS Ah, OK. >The Core JavaScript 1.5specifically states that, that behavior is deprecated. Could be that the behavior is deprecated, but it still seems to work that way. Right, I see that. Don't understand it, but I see it. Do you sometimes feel deprecated and Lost forever too, dreadful sorry, Clementine? I am not sure I understand what you said, but yes, I am lost quite often (front lobe disabilities affect problem solving). Anyway, I never fully understand how parseInt works. I have to read it a thousand times before realizing (for example) that: parseInt('18' 8); should *not* return 22, but parseInt('22', 8); should return 18. -- -Lost Remove the extra words to reply by e-mail. Don't e-mail me. I am kidding. No I am not. Jun 17 '07 #6

 P: n/a -Lost wrote on 17 jun 2007 in comp.lang.javascript: > alert(parseInt('00018')) // returns 1 in IE7 and FF2 Right, I see that. Don't understand it, but I see it. I think [but am not sure] it works this way: 0 octal assumed 00 skipped 1 value is one 8 value over 7 not part of octal number, so 8 is considered to be a letter, parsing ended. result value is 1. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) Jun 17 '07 #7

 P: n/a Evertjan. said the following on 6/17/2007 2:10 PM: -Lost wrote on 17 jun 2007 in comp.lang.javascript: >> alert(parseInt('00018')) // returns 1 in IE7 and FF2 Right, I see that. Don't understand it, but I see it. I think [but am not sure] it works this way: 0 octal assumed 00 skipped 1 value is one 8 value over 7 not part of octal number, so 8 is considered to be a letter, parsing ended. result value is 1. Read the string, from left to right, until you encounter a character that is not in the base set. The string that you have read, up until then, convert it to the base. So, it reads until it finds the 8, stops reading (parseInt('000181111') will also - rightfully - give 1). Then it converts 0001 in Base 8, which is 1. parseInt('0001238') might show it a little easier to see. -- Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq/index.html Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ Jun 17 '07 #8

 P: n/a In comp.lang.javascript message <11**********************@q69g2000hsb.go oglegroups.com>, Sun, 17 Jun 2007 09:55:37, ki*******@gmail.com posted: >Why does parseInt("0000000000000018") return 1, whileparseInt("0000000000000018", 10) return 18?My assumption was that the base 10 would be default argument forradix. Wouldn't you want to get back 18 in most if not all cases?Any thoughts? You should have read the newsgroup FAQ. One section fairly obviously applies. See below. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6 news:comp.lang.javascript FAQ .

 P: n/a In comp.lang.javascript message , Sun, 17 Jun 2007 13:33:54, -Lost posted: >I'd like to know where you read that from. The Core JavaScript 1.5specifically states that, that behavior is deprecated. If something is currently deprecated, it can be assumed to exist. However, it should not be used if there is a non-deprecated alternative, and it should not be relied upon. OTOH, when code is being read, it is well to be able to understand the deprecated construct. The FAQ refers. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.

 P: n/a On Jun 17, 7:33 pm, -Lost

 P: n/a dd wrote: On Jun 17, 7:33 pm, -Lost The Core JavaScript 1.5 specifically statesthat, that behavior is deprecated. JavaScript deprecation rules seem to be following Java. When they say something is deprecated, what they mean is that this method/property is no longer recommended and in future maybe removed from the language. So you really ought not to be using deprecated features because they may just disappear one day, however, they are still there right now and will still work. The big difference between Java and JavaScript though when it comes to deprecation is that there's no compiler involved with JavaScript. This means that there are many millions of web pages out there that might break if deprecated features were actually removed from the language. So it's probably not going to happen. Only Microsoft would do such a thing (re: EOLAS issue). In the Java world, they can stop supporting deprecated features in the compilers (but not in the JVMs) and it can force people to stop using the feature. I don't recall any specific example of Sun doing this though. Just for clarity's sake (well, mainly for me). If browser vendors were to update their JavaScript engines to reflect a deprecated feature, that would then break JavaScript applications. With a Java .class or .jar or whatnot (or whatever the compiled code may become), it would not break if the JVMs were updated to reflect deprecated features. Right? I assume this because the Java code is a compiled version, where the JavaScript code is "compiled" every time it is accessed. -- -Lost Remove the extra words to reply by e-mail. Don't e-mail me. I am kidding. No I am not. Jun 19 '07 #12

 P: n/a -Lost said the following on 6/19/2007 9:25 AM: dd wrote: >On Jun 17, 7:33 pm, -Lost >The Core JavaScript 1.5 specifically statesthat, that behavior is deprecated. JavaScript deprecation rules seem to be following Java.When they say something is deprecated, what they mean isthat this method/property is no longer recommended andin future maybe removed from the language. So you reallyought not to be using deprecated features because theymay just disappear one day, however, they are still thereright now and will still work.The big difference between Java and JavaScript thoughwhen it comes to deprecation is that there's nocompiler involved with JavaScript. This means thatthere are many millions of web pages out therethat might break if deprecated features were actuallyremoved from the language. So it's probably not goingto happen.Only Microsoft would do such a thing (re: EOLAS issue).In the Java world, they can stop supporting deprecatedfeatures in the compilers (but not in the JVMs) and itcan force people to stop using the feature. I don'trecall any specific example of Sun doing this though. Just for clarity's sake (well, mainly for me). If browser vendors were to update their JavaScript engines to reflect a deprecated feature, that would then break JavaScript applications. With a Java .class or .jar or whatnot (or whatever the compiled code may become), it would not break if the JVMs were updated to reflect deprecated features. Right? No. It would break with a new engine if the new engine didn't support deprecated features until the .class,.jar files were recompiled and re-downloaded by the client. -- Randy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq/index.html Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ Jun 19 '07 #13

### This discussion thread is closed

Replies have been disabled for this discussion.