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.

 

[Douglas Crockford]

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]

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/doc...ference:Global_Functions:parseInt#Description

 

[Evertjan.]

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

Evertjan. wrote:

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?

 

[-Lost]

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


MS

Ah, OK.

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.

 

[Evertjan.]

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

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.

 

[Randy Webb]

Evertjan. said the following on 6/17/2007 2:10 PM:

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

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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
oglegroups.com>, Sun, 17 Jun 2007 09:55:37, (e-mail address removed) 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.

 

[Dr J R Stockton]

In comp.lang.javascript message <E9CdnZGwH5q57ejbnZ2dnUVZ_tKjnZ2d@comcas

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.

 

[dd]

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]

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.

 

[Randy Webb]

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

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.