THE integer (or parseInt) inaccuracy all should know about

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • lorlarz

    THE integer (or parseInt) inaccuracy all should know about

    Regarding

    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(((fpss Array[i][j]).toString()).s ubstring((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(parseF loat(((fpssArra y[i]
    [j]).toString()).s ubstring((m*3), (m*3)+3)) + .9);
    TO
    tempx = parseInt(((fpss Array[i][j]).toString()).s ubstring((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

    #2
    Re: THE integer (or parseInt) inaccuracy all should know about

    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[i][j].toString()).le ngth)/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 <lorl...@gmail. comwrote:
    Regardinghttp://mynichecomputin g.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(((fpss Array[i][j]).toString()).s ubstring((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(parseF loat(((fpssArra y[i]
    [j]).toString()).s ubstring((m*3), (m*3)+3)) + .9);
    TO
    tempx = parseInt(((fpss Array[i][j]).toString()).s ubstring((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.

    Comment

    • lorlarz

      #3
      Re: THE integer (or parseInt) inaccuracy all should know about

      A quick P.P.S.

      Having the line like the following:
      tempx = parseInt(parseF loat(((fpssArra y[i]
      [j]).toString()).s ubstring((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(parseF loat(((fpssArra y[i]
      [j]).toString()).s ubstring((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(((fpss Array[i][j]).toString()).s ubstring((m*3),
      (m*3)+3));

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

      This has yet to be explained.

      Comment

      • lorlarz

        #4
        Re: THE integer (or parseInt) inaccuracy all should know about

        On Aug 19, 6:48 pm, lorlarz <lorl...@gmail. comwrote:
        A quick P.P.S.
        >
        Having the line like the following:
        tempx = parseInt(parseF loat(((fpssArra y[i]
        [j]).toString()).s ubstring((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(parseF loat(((fpssArra y[i]
        [j]).toString()).s ubstring((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(((fpss Array[i][j]).toString()).s ubstring((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(parseF loat(((fpssArra y[i]
        [j]).toString()).s ubstring((m*3), (m*3)+3)) + .9);

        line:

        Paste in Sample scoring system:

        (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(((fpss Array[i][j]).toString()).s ubstring((m*3),
        (m*3)+3));

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

        Paste in Sample scoring system:

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







        Comment

        • Richard Cornford

          #5
          Re: THE integer (or parseInt) inaccuracy all should know about

          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.

          Comment

          • lorlarz

            #6
            Re: THE integer (or parseInt) inaccuracy all should know about

            On Aug 20, 3:19 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
            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

            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(((fpss Array[i][j]).toString()).s ubstring((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.

            Comment

            • lorlarz

              #7
              Re: THE integer (or parseInt) inaccuracy all should know about

              On Aug 20, 3:19 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
              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.

              Comment

              Working...