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

Discussion in 'Javascript' started by FAQ server, Aug 25, 2006.

  1. FAQ server

    FAQ server Guest

    -----------------------------------------------------------------------
    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",10) ''

    http://msdn.microsoft.com/library/en-us/script56/html/js56jsmthparseint.asp

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

    http://www.jibbering.com/faq/faq_notes/faq_notes.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.javascript FAQ is at http://www.jibbering.com/faq/.
    The FAQ workers are a group of volunteers.
     
    FAQ server, Aug 25, 2006
    #1
    1. Advertising

  2. JRS: In article <44ee2f77$0$75029$>, dated Thu,
    24 Aug 2006 23:00:01 remote, seen in news:comp.lang.javascript, FAQ
    server <> posted :
    >-----------------------------------------------------------------------
    >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",10) ''


    .... 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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Aug 25, 2006
    #2
    1. Advertising

  3. FAQ server

    Randy Webb Guest

    Dr John Stockton said the following on 8/25/2006 8:13 AM:
    > JRS: In article <44ee2f77$0$75029$>, dated Thu,
    > 24 Aug 2006 23:00:01 remote, seen in news:comp.lang.javascript, FAQ
    > server <> posted :
    >> -----------------------------------------------------------------------
    >> 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",10) ''

    >
    > .... 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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Aug 25, 2006
    #3
  4. JRS: In article <>, dated
    Fri, 25 Aug 2006 16:39:35 remote, seen in news:comp.lang.javascript,
    Randy Webb <> posted :
    >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.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.zip> Timo Salmi's Turbo Pascal FAQ.
     
    Dr John Stockton, Aug 26, 2006
    #4
  5. 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
     
    Michael Winter, Aug 26, 2006
    #5
  6. JRS: In article <EA0Ig.9248$>, dated
    Sat, 26 Aug 2006 18:40:36 remote, seen in news:comp.lang.javascript,
    Michael Winter <> posted :
    >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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Aug 27, 2006
    #6
  7. Dr John Stockton wrote:

    > JRS: In article <EA0Ig.9248$>,
    > dated Sat, 26 Aug 2006 18:40:36 remote, seen in
    > news:comp.lang.javascript, Michael Winter <>
    > 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
     
    Michael Winter, Aug 27, 2006
    #7
  8. JRS: In article <Y4nIg.9853$>, dated
    Sun, 27 Aug 2006 20:16:56 remote, seen in news:comp.lang.javascript,
    Michael Winter <> posted :
    >
    >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.demon.co.uk Turnpike v4.00 MIME. ©
    Web <URL:http://www.merlyn.demon.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.
     
    Dr John Stockton, Aug 28, 2006
    #8
  9. FAQ server

    RobG Guest

    Dr John Stockton wrote:
    > JRS: In article <Y4nIg.9853$>, dated
    > Sun, 27 Aug 2006 20:16:56 remote, seen in news:comp.lang.javascript,
    > Michael Winter <> posted :
    > >
    > >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
     
    RobG, Aug 29, 2006
    #9
  10. JRS: In article <>,
    dated Mon, 28 Aug 2006 23:15:49 remote, seen in
    news:comp.lang.javascript, RobG <> posted :
    >Dr John Stockton wrote:
    >> JRS: In article <Y4nIg.9853$>, dated
    >> Sun, 27 Aug 2006 20:16:56 remote, seen in news:comp.lang.javascript,
    >> Michael Winter <> posted :


    >> 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.com/faq/faq_notes/type_convert.html#tcPrIntRx">
    Javascript Type-Conversion - parseInt with a radix argument</a>
    ...



    <FAQENTRY> 4.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",10)"

    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.value
    or
    Str = form.control.value
    // 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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Aug 30, 2006
    #10
  11. FAQ server

    Randy Webb Guest

    Dr John Stockton said the following on 8/30/2006 1:14 PM:
    > JRS: In article <>,
    > dated Mon, 28 Aug 2006 23:15:49 remote, seen in
    > news:comp.lang.javascript, RobG <> posted :
    >> 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>

    > <FAQENTRY> 4.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",10)"
    >
    > 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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Sep 1, 2006
    #11
  12. JRS: In article <>, dated
    Fri, 1 Sep 2006 14:05:30 remote, seen in news:comp.lang.javascript,
    Randy Webb <> posted :

    ><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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Sep 1, 2006
    #12
  13. FAQ server

    Randy Webb Guest

    Dr John Stockton said the following on 9/1/2006 4:06 PM:
    > JRS: In article <>, dated
    > Fri, 1 Sep 2006 14:05:30 remote, seen in news:comp.lang.javascript,
    > Randy Webb <> posted :
    >
    >> <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('0x0bcd')

    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/js56jsmthparseint.asp>

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

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Sep 2, 2006
    #13
  14. JRS: In article <>, dated
    Fri, 1 Sep 2006 23:04:09 remote, seen in news:comp.lang.javascript,
    Randy Webb <> posted :
    >
    >> 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('0x0bcd')


    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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
     
    Dr John Stockton, Sep 2, 2006
    #14
  15. FAQ server

    Randy Webb Guest

    Dr John Stockton said the following on 9/2/2006 5:15 PM:
    > JRS: In article <>, dated
    > Fri, 1 Sep 2006 23:04:09 remote, seen in news:comp.lang.javascript,
    > Randy Webb <> posted :
    >>> 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('0x0bcd')

    >
    > 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.someForm.someInput.value;

    Where the user enters the data.

    parseInt(inputValue,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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Sep 4, 2006
    #15
  16. JRS: In article <>, dated
    Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang.javascript,
    Randy Webb <> posted :
    >Dr John Stockton said the following on 9/2/2006 5:15 PM:
    >> JRS: In article <>, dated
    >> Fri, 1 Sep 2006 23:04:09 remote, seen in news:comp.lang.javascript,
    >> Randy Webb <> posted :
    >>>> 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.someForm.someInput.value;
    >
    >Where the user enters the data.
    >
    >parseInt(inputValue,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(inputValue) 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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Sep 4, 2006
    #16
  17. FAQ server

    Randy Webb Guest

    Dr John Stockton said the following on 9/4/2006 3:35 PM:
    > JRS: In article <>, dated
    > Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang.javascript,
    > Randy Webb <> posted :


    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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Sep 12, 2006
    #17
  18. JRS: In article <>, dated
    Mon, 11 Sep 2006 22:41:48 remote, seen in news:comp.lang.javascript,
    Randy Webb <> posted :
    >Dr John Stockton said the following on 9/4/2006 3:35 PM:
    >> JRS: In article <>, dated
    >> Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang.javascript,
    >> Randy Webb <> posted :

    >
    >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.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Sep 12, 2006
    #18
  19. FAQ server

    Randy Webb Guest

    Dr John Stockton said the following on 9/12/2006 5:42 PM:
    > JRS: In article <>, dated
    > Mon, 11 Sep 2006 22:41:48 remote, seen in news:comp.lang.javascript,
    > Randy Webb <> posted :
    >> Dr John Stockton said the following on 9/4/2006 3:35 PM:
    >>> JRS: In article <>, dated
    >>> Mon, 4 Sep 2006 05:58:44 remote, seen in news:comp.lang.javascript,
    >>> Randy Webb <> posted :

    >> 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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Sep 14, 2006
    #19
  20. FAQ server

    VK Guest

    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
     
    VK, Sep 14, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,990
    Smokey Grindel
    Dec 2, 2006
  2. Paul Melis

    Why oh why does this NOT give a compile error?

    Paul Melis, Nov 5, 2007, in forum: C Programming
    Replies:
    13
    Views:
    521
    cr88192
    Nov 7, 2007
  3. FAQ server
    Replies:
    0
    Views:
    97
    FAQ server
    Oct 22, 2006
  4. FAQ server
    Replies:
    14
    Views:
    175
    Randy Webb
    Dec 29, 2006
  5. FAQ server
    Replies:
    2
    Views:
    136
    John Hosking
    Aug 17, 2007
Loading...

Share This Page