FAQ Topic - Why does parseInt('09') give an error?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - Why does parseInt('09') give an error?
-----------------------------------------------------------------------

The parseInt function decides what base the number is by looking
at the number. By convention it assumes that any number beginning
with 0x is Hexadecimal, and otherwise any number beginning with
0 is Octal. To force use of base 10 add a second parameter
`` parseInt("09",1 0) ''

http://msdn.microsoft.com/library/en...thparseint.asp

http://docs.sun.com/source/816-6408-...ev.htm#1064173

http://www.jibbering.com/faq/faq_not....html#FAQN4_12
===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javas cript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

[Randy Webb]

Dr John Stockton said the following on 8/30/2006 1:14 PM:

JRS: In article <11************ **********@74g2 000cwt.googlegr oups.com>,
dated Mon, 28 Aug 2006 23:15:49 remote, seen in
news:comp.lang. javascript, RobG <rg***@iinet.ne t.auposted :

>Dr John Stockton wrote:

<snip>

>>For values of numeric properties, given in decimal without leading zero
and possibly followed by a unit (e.g. 33px), parseInt(S) is appropriate.

It is obvious that bases 2..7, 9, 11..15, 17..36 require parseInt(S, B).

Probably not to most. Less condescending is:

"Bases 2..7, 9, 11..15, 17..36 require parseInt(S, B)."

But then someone like Randy will complain about 8 being missing, as
earlier in the thread. "... 17..36 clearly ..." ?

I asked about Base 8 for the same reason that Base 16 can be said to be
beneficial to require the Radix. If you compare the number of cases
where you can reliably omit the Radix compared to the number of cases
where you have to supply it, just going up to Base 16, it becomes
obvious - in a hurry - that always specifying it is the Best Practice.

As for omitting the Base with Base 8, you have a 1 in 8 chance of
getting it right.

<snip>

<FAQENTRY4.12 is
"The parseInt function decides what base the number is by looking at the
number. By convention it assumes any number beginning with 0 is Octal,
and any number beginning with 0x Hexadecimal. To force use of base 10
add a second parameter parseInt("09",1 0)"

and needs to be more like

"If no Base is given, the parseInt function decides what base the number
is in by looking at the number. It assumes that any number beginning
with 0x is Hexadecimal, and may assume that any number beginning with 0
is Octal. To force use of bases 8 or 10 add a second parameter, as in
parseInt("09", 10) or parseInt("077", 8).".
</FAQENTRY>

<FAQENTRY>

"If no Base is given, the parseInt function decides what base the number
is in by looking at the number. It assumes that any number beginning
with 0x is Hexadecimal, and may assume that any number beginning with 0
is Octal. To remove this ambiguity, always use the Radix parameter with
parseInt".
</FAQENTRY>

Don't make it harder than it has to be in a FAQ Entry. In the Notes,
maybe, but anybody with a desire to understand parseInt can master it in
under 10 minutes.
<snip>
--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <_O************ *************** ***@comcast.com >, dated
Fri, 1 Sep 2006 14:05:30 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

><FAQENTRY>

"If no Base is given, the parseInt function decides what base the number
is in by looking at the number. It assumes that any number beginning
with 0x is Hexadecimal, and may assume that any number beginning with 0
is Octal. To remove this ambiguity, always use the Radix parameter with
parseInt".
</FAQENTRY>

Naive. There are circumstances in which it is right for the user to
choose the base from 8, 10, 16. Don't be a Stalinist.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/>? JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Dr John Stockton said the following on 9/1/2006 4:06 PM:

JRS: In article <_O************ *************** ***@comcast.com >, dated
Fri, 1 Sep 2006 14:05:30 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

><FAQENTRY>

"If no Base is given, the parseInt function decides what base the number
is in by looking at the number. It assumes that any number beginning
with 0x is Hexadecimal, and may assume that any number beginning with 0
is Octal. To remove this ambiguity, always use the Radix parameter with
parseInt".
</FAQENTRY>

Naive.

No, what is naive is your belief that parseInt is that difficult and/or
complicated. It isn't.

There are circumstances in which it is right for the user to
choose the base from 8, 10, 16.

There is a need to *always* choose the base for 8 and 10.

Base 8:
parseInt('09') in Opera 9 gives 9. In IE and Mozilla it gives 0. That
alone makes it unreliable on the web to use parseInt for Base 8 without
the Radix.

Base 10:
Again, parseInt('09') gives different results in Opera 9 and other
browsers. That makes it unreliable for web use without the Radix for
Base 10.

That limits your statement to Base 16.
Which means that the *only* time you can *reliably* omit the Radix is
Base 16. And assuming that you are only dealing with Base 2-36 that is
1/35 times that it is reliable. 3%, for me, is not what I would term
"reliable". Nor is it worth the effort to remember it. Use the Radix and
you never have to worry with it. Besides, its about as much typing one
way as the other, 1 character difference:

parseInt('0bcd' ,16)
parseInt('0x0bc d')

1 Character. Yeah, that's a big savings. If you forget that 0x? It gives
0 and you are left scratching your head wondering why.

Yet you call that reasoning "Naive"?

Sidenote: The URL referenced in the FAQ:
<URL:http://msdn.microsoft. com/library/en-us/script56/html/js56jsmthparsei nt.asp>

Redirects to:
<URL:
http://msdn.microsoft. com/library/default.asp?url =/library/en-us/script56/html/e86471af-2a0e-4359-83af-f1ac81e51421.as p>

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <K9************ *************** ***@comcast.com >, dated
Fri, 1 Sep 2006 23:04:09 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>

>There are circumstances in which it is right for the user to
choose the base from 8, 10, 16.

There is a need to *always* choose the base for 8 and 10.

Base 8:
parseInt('09 ') in Opera 9 gives 9. In IE and Mozilla it gives 0. That
alone makes it unreliable on the web to use parseInt for Base 8 without
the Radix.

Having been given an instruction that Hex can be written as 0xfff and
octal as 0777 otherwise decimal, anyone entering "09" deserves whatever
they get.

>Base 10:
Again, parseInt('09') gives different results in Opera 9 and other
browsers. That makes it unreliable for web use without the Radix for
Base 10.

No point in repeating that : parseInt("09") in any browser gives a
result independent of what base the user is hoping for.

Perhaps you have never heard of something called "feature detection"?

The programmer can test parseInt("09") and/or parseInt("077") , and adapt
the instructions seen by the user accordingly; if in his application it
is appropriate for the user to make the choice when typing in each
entry.

document.write( "In this browser, 0... ",
parseInt("077") ==63 ? "can" : "CANNOT",
" be used for Octal input. IAEFRTI.")

>That limits your statement to Base 16.
Which means that the *only* time you can *reliably* omit the Radix is
Base 16. And assuming that you are only dealing with Base 2-36 that is
1/35 times that it is reliable.

It is rare that all bases are equally likely, in my experience.
One can reliably omit the radix for decimal input if leading zeroes will
not be present, as explained previously. Function parseInt has uses
other than the digestion of strings typed by the user.

3%, for me, is not what I would term
"reliable". Nor is it worth the effort to remember it. Use the Radix and
you never have to worry with it. Besides, its about as much typing one
way as the other, 1 character difference:

parseInt('0bcd ',16)
parseInt('0x0b cd')

In the code itself, both of those should be replaced by just 0x0bcd .

But if the average user of the page wishes to choose between Decimal and
Hexadecimal. he will not be able to do so by choosing the second
parameter in that simple fashion. He would need, say, radio-buttons or
another field to choose the base.
You need to distinguish more carefully between what you as a coder can
do and what anyone who may be reading your pages can do.

I trust that you will study the sig of this message.
--
It's a good idea to read the newsgroup and its FAQ.

© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/>? JL/RC: FAQ of news:comp.lang. javascript

[Randy Webb]

Dr John Stockton said the following on 9/2/2006 5:15 PM:

JRS: In article <K9************ *************** ***@comcast.com >, dated
Fri, 1 Sep 2006 23:04:09 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>>There are circumstances in which it is right for the user to
choose the base from 8, 10, 16.

There is a need to *always* choose the base for 8 and 10.

Base 8:
parseInt('09 ') in Opera 9 gives 9. In IE and Mozilla it gives 0. That
alone makes it unreliable on the web to use parseInt for Base 8 without
the Radix.

Having been given an instruction that Hex can be written as 0xfff and
octal as 0777 otherwise decimal, anyone entering "09" deserves whatever
they get.

Your imagination amuses me sometimes. If that were true, then there
would be *NO* need for any kind of data validation at all. And to simply
say "It's the users fault because I, the programmer, don't want to use a
Radix", isn't the user getting what they deserve, it is ignorance on the
part of the programmer.

>Base 10:
Again, parseInt('09') gives different results in Opera 9 and other
browsers. That makes it unreliable for web use without the Radix for
Base 10.

No point in repeating that : parseInt("09") in any browser gives a
result independent of what base the user is hoping for.

With you, you can never tell what needs to be repeated and what doesn't.

Perhaps you have never heard of something called "feature detection"?

Are you kidding me? Write a lot of code to detect how parseInt works
when you can add 2, maybe 3, characters and have no problems at all?
That isn't "feature detection", that is ignorance based on writing code
(in your words here) "by the yard".

The programmer can test parseInt("09") and/or parseInt("077") , and adapt
the instructions seen by the user accordingly; if in his application it
is appropriate for the user to make the choice when typing in each
entry.

There is no need for any of that and it is nothing more than an Academic
Exercise. You add the Radix and you don't have that issue to even consider.

document.write( "In this browser, 0... ",
parseInt("077") ==63 ? "can" : "CANNOT",
" be used for Octal input. IAEFRTI.")

That is a joke isn't it?

>That limits your statement to Base 16.
Which means that the *only* time you can *reliably* omit the Radix is
Base 16. And assuming that you are only dealing with Base 2-36 that is
1/35 times that it is reliable.

It is rare that all bases are equally likely, in my experience.

You are the one that brought up 2-36, not me. But that is your typical
style is to avoid your mistakes.

One can reliably omit the radix for decimal input if leading zeroes will
not be present, as explained previously. Function parseInt has uses
other than the digestion of strings typed by the user.

Provide the Radix and it is *NEVER* an issue.

>3%, for me, is not what I would term
"reliable". Nor is it worth the effort to remember it. Use the Radix and
you never have to worry with it. Besides, its about as much typing one
way as the other, 1 character difference:

parseInt('0bcd ',16)
parseInt('0x0b cd')

In the code itself, both of those should be replaced by just 0x0bcd .

OK, just for you, let me give you an example that just might satisfy
your pedantics.

Assume that your data is coming from a user entered field:

var inputValue = document.someFo rm.someInput.va lue;

Where the user enters the data.

parseInt(inputV alue,16);

Now, will *THAT* satisfy your pedantic stupid arguments?

And don't go back to the "educate your users" hogwash argument.

But if the average user of the page wishes to choose between Decimal and
Hexadecimal. he will not be able to do so by choosing the second
parameter in that simple fashion. He would need, say, radio-buttons or
another field to choose the base.

Aside from your grammatical errors, you don't say?

You need to distinguish more carefully between what you as a coder can
do and what anyone who may be reading your pages can do.

And you need to distinguish more carefully between your pedantic pride
not allowing you to admit when you are wrong and plain common sense.
Stop making it harder than it has to be.

I trust that you will study the sig of this message.

If there were anything in your signature worth studying then I might.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <4v************ *************** ***@comcast.com >, dated
Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>Dr John Stockton said the following on 9/2/2006 5:15 PM:

>JRS: In article <K9************ *************** ***@comcast.com >, dated
Fri, 1 Sep 2006 23:04:09 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>>>There are circumstances in which it is right for the user to
choose the base from 8, 10, 16.
There is a need to *always* choose the base for 8 and 10.

But you would enforce a base, rather than allowing a choice.

>Having been given an instruction that Hex can be written as 0xfff and
octal as 0777 otherwise decimal, anyone entering "09" deserves whatever
they get.

Your imagination amuses me sometimes. If that were true, then there
would be *NO* need for any kind of data validation at all.

The existence of at least one case where data validation is not needed
does not disprove the existence of cases where data validation is
appropriate. You've been following Logic 101 again, and that is known
to be buggy.

>With you, you can never tell what needs to be repeated and what doesn't.

>Perhaps you have never heard of something called "feature detection"?

Are you kidding me? Write a lot of code to detect how parseInt works
when you can add 2, maybe 3, characters and have no problems at all?
That isn't "feature detection", that is ignorance based on writing code
(in your words here) "by the yard".

With two, three, or even as many as four characters, how would you, as a
mere coder, allow the user to choose whether he wants to enter data in
decimal or hexadecimal?

>>That limits your statement to Base 16.
Which means that the *only* time you can *reliably* omit the Radix is
Base 16. And assuming that you are only dealing with Base 2-36 that is
1/35 times that it is reliable.

It is rare that all bases are equally likely, in my experience.

You are the one that brought up 2-36, not me. But that is your typical
style is to avoid your mistakes.

To include the possibility of bases 2 to 36 is by no means to say that
all are equally likely. When did you last use decimal? When did you
last use base 29?

>Provide the Radix and it is *NEVER* an issue.

You, the coder, cannot know the preference of the user in all cases.

>OK, just for you, let me give you an example that just might satisfy
your pedantics.

Assume that your data is coming from a user entered field:

var inputValue = document.someFo rm.someInput.va lue;

Where the user enters the data.

parseInt(input Value,16);

Now, will *THAT* satisfy your pedantic stupid arguments?

That forces base 16, as you should know. It does not allow the user to
choose between decimal and hexadecimal. But parseInt(inputV alue) does
that.

>But if the average user of the page wishes to choose between Decimal and
Hexadecimal. he will not be able to do so by choosing the second
parameter in that simple fashion. He would need, say, radio-buttons or
another field to choose the base.

Aside from your grammatical errors, you don't say?

Now we see that you do not understand the difference between a
grammatical error and a minor typo.

>I trust that you will study the sig of this message.

If there were anything in your signature worth studying then I might.

Without studying it, how could you possibly know? - except for the line
corresponding to one in your own signature.

It's a good idea to read the newsgroup and its FAQ.
--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/>? JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Dr John Stockton said the following on 9/4/2006 3:35 PM:

JRS: In article <4v************ *************** ***@comcast.com >, dated
Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

I snipped everything in your post that was irrelevant to the FAQ Entry
that this thread was started on. If you want to give people the advice
to try to feature detect how to deal with Base 8, then please do. I will
reply back with how ignorant that idea is. Same for Base 10 and Base 16.
There is a very simple solution to it:

Always use the Radix and it will never matter.

I now return you all to your regularly scheduled CLJ noise of VK's posts.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <pq************ *************** ***@comcast.com >, dated
Mon, 11 Sep 2006 22:41:48 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>Dr John Stockton said the following on 9/4/2006 3:35 PM:

>JRS: In article <4v************ *************** ***@comcast.com >, dated
Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

I snipped everything in your post that was irrelevant to the FAQ Entry
that this thread was started on. If you want to give people the advice
to try to feature detect how to deal with Base 8, then please do. I will
reply back with how ignorant that idea is. Same for Base 10 and Base 16.
There is a very simple solution to it:

Always use the Radix and it will never matter.

That's a control-freak policy, and if used by the coder it deprives the
user of the choice of radix between 8, 10, 16 (8 only in some browsers;
but that's a user choice).

Probably your experience is largely limited to the commercial world,
where the only numbers deal with amounts of money and quantities of
goods, both customarily represented in decimal. In the wider world
there are applications in which it would be appropriate to allow the
user to choose between decimal and hexadecimal directly, without
auxiliary controls.

A FAQ entry should not be unnecessarily restrictive.

It's a good idea to read the newsgroup and its FAQ.
--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/>? JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Dr John Stockton said the following on 9/12/2006 5:42 PM:

JRS: In article <pq************ *************** ***@comcast.com >, dated
Mon, 11 Sep 2006 22:41:48 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>Dr John Stockton said the following on 9/4/2006 3:35 PM:

>>JRS: In article <4v************ *************** ***@comcast.com >, dated
Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

I snipped everything in your post that was irrelevant to the FAQ Entry
that this thread was started on. If you want to give people the advice
to try to feature detect how to deal with Base 8, then please do. I will
reply back with how ignorant that idea is. Same for Base 10 and Base 16.
There is a very simple solution to it:

Always use the Radix and it will never matter.

That's a control-freak policy,

No, it's a fool-proof code policy.

and if used by the coder it deprives the user of the choice of radix
between 8, 10, 16 (8 only in some browsers; but that's a user choice).

No, the coder still has the ability to give the user that choice.

Probably your experience is largely limited to the commercial world,
where the only numbers deal with amounts of money and quantities of
goods, both customarily represented in decimal.

Yes, it is largely limited to the commercial world although I have
volunteered to help with scripts in the scientific world where the Base
is not always 10.

In the wider world there are applications in which it would be
appropriate to allow the user to choose between decimal and hexadecimal
directly, without auxiliary controls.

Example of that scenario?

A FAQ entry should not be unnecessarily restrictive.

It should also promote the best practice and not specifying the Radix is
a recipe for disaster for 99% of the people who would be looking that up
in the FAQ.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

Randy Webb wrote:

(VK highlights with **)

<FAQENTRY>

"If no *base encoding* is given, the parseInt function decides what base the number
is in by looking at the number. It assumes that any number beginning
with 0x is Hexadecimal, and may assume that any number beginning with 0
is Octal. To remove this ambiguity, always use the Radix parameter with
parseInt".
</FAQENTRY>

Perfect.

As OT in FAQ comments it is possible to discuss the IQ level of that
C'er who decided to prefix octals with 0 (zero) and hexs with 0x
instead of say o77 and hFF, but it will not change the standards so now
useless

Don't make it harder than it has to be in a FAQ Entry. In the Notes,
maybe, but anybody with a desire to understand parseInt can master it in
under 10 minutes.

Full ACK