parseInt() question

[kilik3000]

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

[Evertjan.]

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)

[Douglas Crockford]

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/

[-Lost]

Evertjan. wrote:

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.

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.

[Evertjan.]

-Lost wrote on 17 jun 2007 in comp.lang.javascript:

Evertjan. wrote:

>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.

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.

<script type='text/javascript'>
alert(parseInt('00018')) // returns 1 in IE7 and FF2
</script>

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)

[-Lost]

Evertjan. wrote:

-Lost wrote on 17 jun 2007 in comp.lang.javascript:

>Evertjan. wrote:

>>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.

MS

Ah, OK.

>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.

<script type='text/javascript'>
alert(parseInt('00018')) // returns 1 in IE7 and FF2
</script>

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.

[Evertjan.]

-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)

[Randy Webb]

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/

[Dr J R Stockton]

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, 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?

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 <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Dr J R Stockton]

In comp.lang.javascript message <E9CdnZGwH5q57ejbnZ2dnUVZ_tKjnZ2d@comcas
t.com>, Sun, 17 Jun 2007 13:33:54, -Lost <ma****************@techie.com>
posted:

>
I'd like to know where you read that from. The Core JavaScript 1.5
specifically 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.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.

[dd]

On Jun 17, 7:33 pm, -Lost <[e-mail]:

The Core JavaScript 1.5 specifically states
that, 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.

[-Lost]

dd wrote:

On Jun 17, 7:33 pm, -Lost <[e-mail]:

>The Core JavaScript 1.5 specifically states
that, 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.

[Randy Webb]

-Lost said the following on 6/19/2007 9:25 AM:

dd wrote:

>On Jun 17, 7:33 pm, -Lost <[e-mail]:

>>The Core JavaScript 1.5 specifically states
that, 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?

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/