THE integer (or parseInt) inaccuracy all should know about

Discussion in 'Javascript' started by lorlarz, Aug 19, 2008.

  1. lorlarz

    lorlarz Guest

    Regarding
    http://mynichecomputing.com/digitallearning/yourOwn.htm
    and how to make it fail when it should not with an integer OR
    parseInt to integer conversion problem.


    THE real problem IS is that simply doing the following ,
    tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    (m*3)+3));
    does NOT work.

    This show show an integer problem (or parseInt problem) that there
    SHOULDN'T
    BE.

    I am truly embarrassed for previously not having set up the proper
    experiment
    which does show
    an integer problem and do apologize to the group. The experiment NOW
    though has been indicated and it there to show something that shows
    an
    unexpected integer (OR parseInt) problem.

    IN THE TXT FILE MENTIONED AT THE TOP OF THE POST:
    One must change that line, not only omitting the .9 but also
    omitting the intermediate parseFloat conversion to see the problem I
    saw.

    THUS, If one changes the line
    tempx = parseInt(parseFloat(((fpssArray
    [j]).toString()).substring((m*3),(m*3)+3)) + .9);
    TO
    tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    (m*3)+3));

    THE INTEGER PROBLEM OR PARSEINT PROBLEM DOES OCCUR.
    I just tested it and
    verified it.

    I have only proprietary scoring systems. SO: You simply have to make
    your own
    (as described). Sorry.

    In summary:
    There is an integer (or parseInt) problem which needs to be known
    about.
    I had forgotten 2 changes were involved in fixing the problem. How
    to
    recreate the problem has now been clearly indicated.
    lorlarz, Aug 19, 2008
    #1
    1. Advertising

  2. lorlarz

    lorlarz Guest

    P.S. Addressing the division by three in the program mentioned
    by Lasse Reichstein Nielsen in the other "corrupted thread" as a
    possible problem
    It is here:
    m<Math.floor(((fpssArray[j].toString()).length)/3);

    If indeed m were COMPARED DIRECTLY TO a value divided by three, I
    could imagine a problem. But, m is compare only to an integer,
    from Math.floor(...). Thus no comparison with a non-integer occurs.

    There is no explanation for the scoring miscounts in the
    experiment, as I have now correctly described it, except
    a parseInt or integer problem (in either case, what I would
    call an integer inaccuracy problem).


    On Aug 19, 5:51 pm, lorlarz <> wrote:
    > Regardinghttp://mynichecomputing.com/digitallearning/yourOwn.htm
    > and how to make it fail when it should not with an integer OR
    > parseInt to integer conversion problem.
    >
    > THE real problem IS  is that simply doing the following ,
    > tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    > (m*3)+3));
    > does NOT work.
    >
    > This show show an integer problem (or parseInt problem) that there
    > SHOULDN'T
    > BE.
    >
    >  I am truly embarrassed for previously not having set up the proper
    > experiment
    > which does show
    > an integer problem and do apologize to the group.  The experiment NOW
    > though has been indicated and it there to show something that shows
    > an
    > unexpected integer (OR parseInt) problem.
    >
    > IN THE TXT FILE MENTIONED AT THE TOP OF THE POST:
    > One must change that line, not only omitting the .9 but also
    > omitting the intermediate parseFloat conversion to see the problem I
    > saw.
    >
    > THUS, If one changes the line
    > tempx = parseInt(parseFloat(((fpssArray
    > [j]).toString()).substring((m*3),(m*3)+3)) + .9);
    > TO
    > tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    > (m*3)+3));
    >
    > THE INTEGER PROBLEM OR PARSEINT PROBLEM DOES OCCUR.
    >  I just tested it and
    > verified it.
    >
    > I have only proprietary scoring systems.  SO: You simply have to make
    > your own
    > (as described).  Sorry.
    >
    > In summary:
    > There is an integer (or parseInt) problem which needs to be known
    > about.
    > I had forgotten 2 changes were involved in fixing the problem.  How
    > to
    > recreate the problem has now been clearly indicated.
    lorlarz, Aug 20, 2008
    #2
    1. Advertising

  3. lorlarz

    lorlarz Guest

    A quick P.P.S.

    Having the line like the following:
    tempx = parseInt(parseFloat(((fpssArray
    [j]).toString()).substring((m*3),(m*3)+3)) + .9);

    is the solution to the integer or parseInt problem.
    (That is why you have to change it in a couple of ways to do
    the experiment to see the integer problem).

    In the other thread:
    The parseInt in the line of code was confounding (messing up) the
    experiment which SHOWS the integer or parseInt inaccuracy
    or error (and *only in _that sense_* is this above line
    a "problem" -- i.e. it corrupted the experiment showing the
    problem).

    Again THIS LINE,

    tempx = parseInt(parseFloat(((fpssArray
    [j]).toString()).substring((m*3),(m*3)+3)) + .9);

    ALL SHOULD KNOW IS THE **SOLUTION** and the way to
    yield correct instead of incorrect RESULTS.

    Again, The line that yields an unexpected problem is:

    tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    (m*3)+3));

    No parseFloat there and nothing is being compared to any float!!

    This has yet to be explained.
    lorlarz, Aug 20, 2008
    #3
  4. lorlarz

    lorlarz Guest

    On Aug 19, 6:48 pm, lorlarz <> wrote:
    > A quick P.P.S.
    >
    > Having the line like the following:
    > tempx = parseInt(parseFloat(((fpssArray
    > [j]).toString()).substring((m*3),(m*3)+3)) + .9);
    >
    > is the solution to the integer or parseInt problem.
    > (That is why you have to change it in a couple of ways to do
    >  the experiment to see the integer problem).
    >
    > In the other thread:
    > The parseInt in the line of code was confounding (messing up) the
    > experiment which SHOWS the integer or parseInt inaccuracy
    > or error (and *only in _that sense_* is this above line
    > a "problem" -- i.e. it corrupted the experiment showing the
    > problem).
    >
    > Again  THIS LINE,
    >
    > tempx = parseInt(parseFloat(((fpssArray
    > [j]).toString()).substring((m*3),(m*3)+3)) + .9);
    >
    > ALL SHOULD KNOW IS THE **SOLUTION** and the way to
    > yield correct instead of incorrect RESULTS.
    >
    > Again, The line that yields an unexpected problem is:
    >
    > tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    > (m*3)+3));
    >
    > No parseFloat there and nothing is being compared to any float!!
    >
    > This has yet to be explained.


    Ok. I will do the work for all you lazy rude thankless people:

    First let's use the good (the fixed) version with the
    tempx = parseInt(parseFloat(((fpssArray
    [j]).toString()).substring((m*3),(m*3)+3)) + .9);

    line:

    Paste in Sample scoring system:
    http://mynichecomputing.com/testIntProb/samplScoring.txt
    (paste it in http://mynichecomputing.com/testIntProb/oldTest.html
    with the cursor sitting right after the last zero)

    Click DoIt Button.

    Paste the true answer set into that same textarea:
    http://mynichecomputing.com/testIntProb/Tans.txt (cursor right after
    the last
    character)

    Click DoIt button again and observe results.

    --------------
    --------------


    NOW, LET'S DO IT WITH THE BAD VERSION: This is the version
    with the
    tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    (m*3)+3));

    line: http://mynichecomputing.com/testIntProb/testNew.html

    Paste in Sample scoring system:
    http://mynichecomputing.com/testIntProb/samplScoring.txt
    (paste it in http://mynichecomputing.com/testIntProb/testNew.html
    with the cursor sitting right after the last zero)

    Click DoIt Button

    Paste the true answer set into that same textarea:
    http://mynichecomputing.com/testIntProb/Tans.txt (cursor right after
    the last
    character)

    Click DoIt button again and observe results.

    --------------


    THERE, that's your proof. EXPLAIN IT.
    lorlarz, Aug 20, 2008
    #4
  5. lorlarz <> writes:

    > Regarding
    > http://mynichecomputing.com/digitallearning/yourOwn.htm
    > and how to make it fail when it should not with an integer OR
    > parseInt to integer conversion problem.
    >
    >
    > THE real problem IS is that simply doing the following ,
    > tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    > (m*3)+3));
    > does NOT work.


    Could you tell us:
    1. What the value if fpssArray[j] and m are that causes it to fail?
    2. What result you expect for those values that you doesn't get?
    It should be simple since you just tested it.

    In order to properly discuss a failure or error, we need to establish
    common ground. That includes agreeing on a way to reproduce, recognize
    and repair the failure (i.e., what did you do, exactly enough that we
    can do exactly the same, what was the error you experienced ("does not work"
    is far from being precise enough), and what result were you expecting).
    These three things are always necessary when reporting a bug, if anything
    is to come of the bug report - and this does seem to be a bug report.


    > THE INTEGER PROBLEM OR PARSEINT PROBLEM DOES OCCUR.
    > I just tested it and
    > verified it.


    Good. Give us the data to reproduce it. Since you have located the
    error to a single line, all we need are the values of the variables
    that causes that line to give a result different from your expectation.

    > I have only proprietary scoring systems. SO: You simply have to make
    > your own
    > (as described). Sorry.


    No, that is not good enough. Maybe the problem you experience only
    happens for a particular set of data, and we could be writing our
    own scoring systems for ages before seeing the problem.

    > In summary:
    > There is an integer (or parseInt) problem which needs to be known
    > about.
    > I had forgotten 2 changes were involved in fixing the problem. How
    > to
    > recreate the problem has now been clearly indicated.


    Not clearly enough, sorry. We might enter a scoring system that doesn't
    give the problem, or we might not recognize the problem, since you
    haven't said what the problem is, just that there is one.

    /L
    --
    Lasse Reichstein Nielsen
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Aug 20, 2008
    #5
  6. lorlarz wrote:
    <snip>
    THERE, that's your proof. EXPLAIN IT.

    As you have a copy of JavaScript: The Good Parts, look up - parseInt -
    in the index (it is page 104: in the "Awful Parts" appendix) and read
    the second paragraph. This is also covered in the group's FAQ.

    Richard.
    Richard Cornford, Aug 20, 2008
    #6
  7. lorlarz

    lorlarz Guest

    On Aug 20, 3:19 am, "Richard Cornford" <>
    wrote:
    > lorlarz wrote:
    >
    > <snip>
    > THERE, that's your proof.  EXPLAIN  IT.
    >
    > As you have a copy of JavaScript: The Good Parts, look up - parseInt -
    > in the index (it is page 104: in the "Awful Parts" appendix) and read
    > the second paragraph. This is also covered in the group's FAQ.
    >
    > Richard.


    Fortunately, I have the book and did read it. I guess I did not
    process
    the appendices thoroughly (or apply all they said to all my programs
    that
    are years old). I reread page 104.

    Indeed, if you change the key line in
    http://mynichecomputing.com/testIntProb/testNew.html
    to include the optional radix paramater
    (the base) (and I want base 10), the problem seems to disappear:

    So making the key line read,
    tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    (m*3)+3),10);
    seems to work.

    On first run, that appears to fix things without the workaround I
    previously used.

    Thanks for your information.
    lorlarz, Aug 20, 2008
    #7
  8. lorlarz

    lorlarz Guest

    On Aug 20, 12:13 am, Lasse Reichstein Nielsen <> wrote:
    > lorlarz <> writes:
    > > Regarding
    > >http://mynichecomputing.com/digitallearning/yourOwn.htm
    > > and how to make it fail when it should not with an integer OR
    > > parseInt to integer conversion problem.

    >
    > > THE real problem IS  is that simply doing the following ,
    > > tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
    > > (m*3)+3));
    > > does NOT work.

    >
    > Could you tell us:
    > 1. What the value if fpssArray[j] and m are that causes it to fail?
    > 2. What result you expect for those values that you doesn't get?
    > It should be simple since you just tested it.
    >
    > In order to properly discuss a failure or error, we need to establish
    > common ground. That includes agreeing on a way to reproduce, recognize
    > and repair the failure (i.e., what did you do, exactly enough that we
    > can do exactly the same, what was the error you experienced ("does not work"
    > is far from being precise enough), and what result were you expecting).
    > These three things are always necessary when reporting a bug, if anything
    > is to come of the bug report - and this does seem to be a bug report.
    >



    The expected result when entering the 600 True responses is for all
    scales
    to have a match (or "correct") count of 30, since each scale is scored
    up
    for "a" or "T" (true) and all sample client answers in the sample
    answer txt
    file are T _and_ each scale is scored up for thirty (30) items.


    > > THE INTEGER PROBLEM OR PARSEINT PROBLEM DOES OCCUR.
    > >  I just tested it and
    > > verified it.

    >
    > Good. Give us the data to reproduce it. Since you have located the
    > error to a single line, all we need are the values of the variables
    > that causes that line to give a result different from your expectation.
    >
    > > I have only proprietary scoring systems.  SO: You simply have to make
    > > your own
    > > (as described).  Sorry.

    >
    > No, that is not good enough. Maybe the problem you experience only
    > happens for a particular set of data, and we could be writing our
    > own scoring systems for ages before seeing the problem.


    You are correct. Fortunately Cornford has the KNOWN reason for the
    problem and the answer.

    >
    > > In summary:
    > > There is an integer (or parseInt) problem which needs to be known
    > > about.
    > > I had forgotten 2 changes were involved in fixing the problem.  How
    > > to
    > > recreate the problem has now been clearly indicated.

    >
    > Not clearly enough, sorry. We might enter a scoring system that doesn't
    > give the problem, or we might not recognize the problem, since you
    > haven't said what the problem is, just that there is one.



    Ditto my last remark above.

    >
    > /L
    > --
    > Lasse Reichstein Nielsen
    >  DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    >   'Faith without judgement merely degrades the spirit divine.'
    lorlarz, Aug 20, 2008
    #8
  9. lorlarz

    lorlarz Guest

    On Aug 20, 3:19 am, "Richard Cornford" <>
    wrote:
    > lorlarz wrote:
    >
    > <snip>
    > THERE, that's your proof.  EXPLAIN  IT.
    >
    > As you have a copy of JavaScript: The Good Parts, look up - parseInt -
    > in the index (it is page 104: in the "Awful Parts" appendix) and read
    > the second paragraph. This is also covered in the group's FAQ.
    >
    > Richard.


    Not wanting to cast any aspersions on my favorite programming
    language, let me
    add as a P.S. that the "problem" I had was actually related to an
    understandable
    FEATURE of the parseInt function. So, this is not like an error,
    _except_ in the
    sense that the radix (base) argument has to be KNOWN to be required if
    any leading
    zeros might be involved.

    The base is NOT optional in cases where there may be leading zeros
    because of "features" of the parseInt function,
    seeing things as octal if they begin with zero and then not
    recognizing the
    digits 8 and 9.

    Thanks again. Perhaps all this was not a total waste of time for
    those
    who were thoroughly knowledgeable. I do supply an illustration of
    the
    problem which might "bring it home" for some in the future.
    lorlarz, Aug 20, 2008
    #9
    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. Knute Johnson

    Interesting Integer.parseInt() problem

    Knute Johnson, Jan 31, 2006, in forum: Java
    Replies:
    4
    Views:
    12,442
    Roedy Green
    Jan 31, 2006
  2. Paul Rubin
    Replies:
    3
    Views:
    693
    jose isaias cabrera
    Feb 1, 2005
  3. Bill Mill
    Replies:
    0
    Views:
    357
    Bill Mill
    Feb 1, 2005
  4. jose isaias cabrera

    Re: Java Integer.ParseInt translation to python

    jose isaias cabrera, Feb 1, 2005, in forum: Python
    Replies:
    0
    Views:
    564
    jose isaias cabrera
    Feb 1, 2005
  5. jose isaias cabrera

    Re: Java Integer.ParseInt translation to python

    jose isaias cabrera, Feb 9, 2005, in forum: Python
    Replies:
    6
    Views:
    2,387
    comp.lang.java
    Feb 10, 2005
Loading...

Share This Page