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.

[Dr John Stockton]

JRS: In article <44************ ***********@new s.sunsite.dk>, dated Thu,
24 Aug 2006 23:00:01 remote, seen in news:comp.lang. javascript, FAQ
server <ja********@dot internet.bepost ed :

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

.... or use +"09" .


IMHO, parseInt should be used only when at least one of these applies :-
The base is neither 10, nor 16 indicated by 0x
The base is variable
The string may have trailing non-whitespace
The string may be empty, to give NaN not 0.

In particular, it should not be used for a match to /^\s*\d+\s*$/

That may be incomplete or sub-optimal - think about exceptions such as
an empty string.
--
© 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 8/25/2006 8:13 AM:

JRS: In article <44************ ***********@new s.sunsite.dk>, dated Thu,
24 Aug 2006 23:00:01 remote, seen in news:comp.lang. javascript, FAQ
server <ja********@dot internet.bepost ed :

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

.... or use +"09" .


IMHO, parseInt should be used only when at least one of these applies :-
The base is neither 10, nor 16 indicated by 0x

Why exclude base 16 but not base 8?

--
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 <xI************ *************** ***@comcast.com >, dated
Fri, 25 Aug 2006 16:39:35 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>Dr John Stockton said the following on 8/25/2006 8:13 AM:

>IMHO, parseInt should be used only when at least one of these applies :-
The base is neither 10, nor 16 indicated by 0x

Why exclude base 16 but not base 8?

That only excludes "base 16 indicated by 0x". A numeric string starting
"0x" should be interpreted as Hex, and will be by other methods. To
parseInt, it is zero in any base other than 16 34 35 36.

For bases 2..7, 9, 11..16, 17..36 parseInt must be used. Otherwise, a
string of non-negative integer value, after trimming non-numeric parts,
can be of the forms
2345 decimal unary + preferred
0123 decimal unary + preferred
0x6e4 hexadecimal unary + preferred
0123 octal must use parseInt
--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demo n.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.

[Michael Winter]

Dr John Stockton wrote:

[snip]

A numeric string starting "0x" should be interpreted as Hex, and will
be by other methods. To parseInt, it is zero in any base other than
16 34 35 36.

And the leading zero is inconsequential for the latter three.

For bases 2..7, 9, 11..16, 17..36 parseInt must be used.

You mean: 2..9, 11..15, and 17..36.

[snip]

Mike

[Dr John Stockton]

JRS: In article <EA************ *****@text.news .blueyonder.co. uk>, dated
Sat, 26 Aug 2006 18:40:36 remote, seen in news:comp.lang. javascript,
Michael Winter <m.******@bluey onder.co.ukpost ed :

>Dr John Stockton wrote:

[snip]

>A numeric string starting "0x" should be interpreted as Hex, and will
be by other methods. To parseInt, it is zero in any base other than
16 34 35 36.

And the leading zero is inconsequential for the latter three.

The leading zero itself is unimportant; the above refers to a leading
"0x". But the first sentence does need an "unless another base is
explicitly indicated".

>For bases 2..7, 9, 11..16, 17..36 parseInt must be used.

You mean: 2..9, 11..15, and 17..36.

NO. The quoted line is exactly what I meant (apart from the obvious
16/15 typo); it deals with all bases for which both parseInt and a
second parameter are immediately and obviously necessary, which is those
other than 8, 10, and 16. It does NOT say anything about bases 8, 10,
16, leaving them for further consideration.

"A implies B" does not imply "not A implies not B" or "B
implies A" .

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

[Michael Winter]

Dr John Stockton wrote:

JRS: In article <EA************ *****@text.news .blueyonder.co. uk>,
dated Sat, 26 Aug 2006 18:40:36 remote, seen in
news:comp.lang. javascript, Michael Winter <m.******@bluey onder.co.uk>
posted :

>Dr John Stockton wrote:

[snip]

>>For bases 2..7, 9, 11..16, 17..36 parseInt must be used.

You mean: 2..9, 11..15, and 17..36.

NO. The quoted line is exactly what I meant (apart from the obvious
16/15 typo); it deals with all bases for which both parseInt and a
second parameter are immediately and obviously necessary, which is
those other than 8, 10, and 16.

Only base-16 is guaranteed to be recognised automatically by the
parseInt function and only when "0x" prefixes the number; decimal is
assumed, otherwise. Octal may be recognised if the string begins with
zero (0), but that occurs at the discretion of the implementation. The
recommendation of the ECMAScript specification is /not/ to make octal a
special case, and there are browsers that follow that recommendation
(Opera, for example). Therefore, if one wishes to use the parseInt
function to convert an octal string to a number, the second argument
/is/ necessary.

[snip]

Mike

[Dr John Stockton]

JRS: In article <Y4************ *****@text.news .blueyonder.co. uk>, dated
Sun, 27 Aug 2006 20:16:56 remote, seen in news:comp.lang. javascript,
Michael Winter <m.******@bluey onder.co.ukpost ed :

>
Only base-16 is guaranteed

Second draft :

For converting a (possibly signed) base-B digit string, S, to a Number,
function parseInt should be used only when beneficial, as alternatives
are longer or slower.

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

Otherwise, a string of non-negative integer value, after trimming
non-numeric parts, can be of the forms :

S B Conversion Note
0123 8 use parseInt(S, 8) 1
0123 10 unary + preferred
2345 10 unary + preferred
0x6b4 16 unary + preferred
6b4 16 use parseInt(S, 16)

Notes :

1: B is required for compatibility with ECMA 262 3rd Edn, and for
compatibility with all browsers.

TBD - consideration of use of minus.

--
© John Stockton, Surrey, UK. ??*@merlyn.demo n.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/- FAQish topics, acronyms, & links.
In MS OE, choose Tools, Options, Send; select Plain Text for News and E-mail.
Don't quote more than is needed, and respond after each quoted part.

[RobG]

Dr John Stockton wrote:

JRS: In article <Y4************ *****@text.news .blueyonder.co. uk>, dated
Sun, 27 Aug 2006 20:16:56 remote, seen in news:comp.lang. javascript,
Michael Winter <m.******@bluey onder.co.ukpost ed :

Only base-16 is guaranteed

Second draft :

For converting a (possibly signed) base-B digit string, S, to a Number,

I'd get rid of the parenthesis:

"For converting a possibly signed base-B digit string, S, to a
Number..."

function parseInt should be used only when beneficial, as alternatives
are longer or slower.

That doesn't make sense - to me it reads "don't use parseInt because
it's faster and shorter than alternatives".

Did you really mean:

"function parseInt should be used only when beneficial, as
it is longer or slower than alternatives."

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

[...]

How about:

For converting a possibly signed base-B digit string, S, to a Number,
function parseInt should be used only when beneficial, as it is
longer or slower than alternatives.

For values of numeric properties, given in decimal without a leading
zero and possibly followed by a unit (such as when getting the value
of a style property, e.g. 33px), parseInt(S) is appropriate.

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

Bases 8, 10 and 16, where S is a string of non-negative integer value
and non-numeric parts have been trimmed (e.g. 09kg has been trimmed
to 09), can be of the forms:

S B Conversion Note
0123 8 use parseInt(S, 8) 1
0123 10 unary + preferred 2
2345 10 unary + preferred 2
0x6b4 16 unary + preferred
6b4 16 use parseInt(S, 16)

Notes :

1: B is required for compatibility with ECMA 262 3rd Edn, and
for compatibility with all browsers.
2: Common when converting the value of form controls to Number.
--
Rob

[Dr John Stockton]

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:

>JRS: In article <Y4************ *****@text.news .blueyonder.co. uk>, dated
Sun, 27 Aug 2006 20:16:56 remote, seen in news:comp.lang. javascript,
Michael Winter <m.******@bluey onder.co.ukpost ed :

>function parseInt should be used only when beneficial, as alternatives
are longer or slower.

That doesn't make sense - to me it reads "don't use parseInt because
it's faster and shorter than alternatives".

It should make perfect nonsense, as I was concentrating on clarity and
totally forgot to check what might be called the polarity of the
statement :-( .

>Did you really mean:

"function parseInt should be used only when beneficial, as
it is longer or slower than alternatives."

Well, maybe ... "as alternatives are shorter and faster."

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

>How about:

For converting a possibly signed base-B digit string, S, to a Number,
function parseInt should be used only when beneficial, as it is
longer or slower than alternatives.

and

>
For values of numeric properties, given in decimal without a leading
zero and possibly followed by a unit (such as when getting the value
of a style property, e.g. 33px), parseInt(S) is appropriate.

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

Bases 8, 10 and 16, where S is a string of non-negative integer value
and non-numeric parts have been trimmed (e.g. 09kg has been trimmed
to 09), can be of the forms:

S B Conversion Note
0123 8 use parseInt(S, 8) 1
0123 10 unary + preferred 2
2345 10 unary + preferred 2
0x6b4 16 unary + preferred
6b4 16 use parseInt(S, 16)

Notes :

1: B is required for compatibility with ECMA 262 3rd Edn, and
for compatibility with all browsers.
2: Common when converting the value of form controls to Number.

Looks good.

It needs to be compared with the FAQ note
<li><a href=
"http://www.jibbering.c om/faq/faq_notes/type_convert.ht ml#tcPrIntRx">
Javascript Type-Conversion - parseInt with a radix argument</a>
...

<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>
FAQ NOTES : type_convert

In table "Double NOT (!!col) : Other Values." and elsewhere, "return;"
serves no apparent purpose?

Just before heading "Converting to String", around "can avoid generating
errors" : IMHO it should note that, while no error will be raised by the
browser, an intention of the programmer may not be fulfilled and
alternative provision should be considered.

In "Converting to String", "the type-conversion mechanism is rarely
suited" - not so - not "rarely". It is suited to handling the results
of integer computation, and computation should be in integers where
practical (e.g. money).

In "Converting to Number", I would recommend, for safety and efficiency,
that the value of a numeric entry is generally converted to Number on
acquisition (rather than using repeated auto-conversion) :

Num = + form.control.va lue
or
Str = form.control.va lue
// Validate Str by RegExp
Num = + Str
"Strings that cannot be read as a number type-convert to NaN," - except
"Infinity", "+Infinity" , "-Infinity" !

In "Parsing to Number", para 2 does not mention leading whitespace.

ISTM that it would be useful for each FAQ Note to contain a plaintext
date, altered at any significant change.
Something rather like our text above could be put into that section.
Inserted, with minor editing, in <URL:http://www.merlyn.demon.co.uk/js-
maths.htm>.

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