parseInt() question

Discussion in 'Javascript' started by kilik3000@gmail.com, Jun 17, 2007.

  1. Guest

    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
     
    , Jun 17, 2007
    #1
    1. Advertising

  2. Evertjan. Guest

    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)
     
    Evertjan., Jun 17, 2007
    #2
    1. Advertising

  3. 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/
     
    Douglas Crockford, Jun 17, 2007
    #3
  4. -Lost Guest

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

    --
    -Lost
    Remove the extra words to reply by e-mail. Don't e-mail me. I am
    kidding. No I am not.
     
    -Lost, Jun 17, 2007
    #4
  5. Evertjan. Guest

    -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)
     
    Evertjan., Jun 17, 2007
    #5
  6. -Lost Guest

    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.
     
    -Lost, Jun 17, 2007
    #6
  7. Evertjan. Guest

    -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)
     
    Evertjan., Jun 17, 2007
    #7
  8. Randy Webb Guest

    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/
     
    Randy Webb, Jun 17, 2007
    #8
  9. In comp.lang.javascript message <
    oglegroups.com>, Sun, 17 Jun 2007 09:55:37, 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.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr J R Stockton, Jun 18, 2007
    #9
  10. In comp.lang.javascript message <E9CdnZGwH5q57ejbnZ2dnUVZ_tKjnZ2d@comcas
    t.com>, Sun, 17 Jun 2007 13:33:54, -Lost <>
    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.zip> Timo Salmi's Turbo Pascal FAQ.
     
    Dr J R Stockton, Jun 18, 2007
    #10
  11. dd Guest

    On Jun 17, 7:33 pm, -Lost <> wrote:
    > 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.
     
    dd, Jun 19, 2007
    #11
  12. -Lost Guest

    dd wrote:
    > On Jun 17, 7:33 pm, -Lost <> wrote:
    >> 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.
     
    -Lost, Jun 19, 2007
    #12
  13. Randy Webb Guest

    -Lost said the following on 6/19/2007 9:25 AM:
    > dd wrote:
    >> On Jun 17, 7:33 pm, -Lost <> wrote:
    >>> 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/
     
    Randy Webb, Jun 19, 2007
    #13
    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. Sam Iam
    Replies:
    6
    Views:
    4,009
    satdmail
    Jul 19, 2006
  2. Knute Johnson

    Interesting Integer.parseInt() problem

    Knute Johnson, Jan 31, 2006, in forum: Java
    Replies:
    4
    Views:
    12,524
    Roedy Green
    Jan 31, 2006
  3. Paul Rubin
    Replies:
    3
    Views:
    721
    jose isaias cabrera
    Feb 1, 2005
  4. Bill Mill
    Replies:
    0
    Views:
    374
    Bill Mill
    Feb 1, 2005
  5. jose isaias cabrera

    Re: Java Integer.ParseInt translation to python

    jose isaias cabrera, Feb 1, 2005, in forum: Python
    Replies:
    0
    Views:
    581
    jose isaias cabrera
    Feb 1, 2005
Loading...

Share This Page