THE integer (or parseInt) inaccuracy all should know about

[lorlarz]

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[i][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[i]
[j]).toString()).substring((m*3),(m*3)+3)) + .9);
TO
tempx = parseInt(((fpssArray[i][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]

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()).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 <[e-mail]:

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[i][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[i]
[j]).toString()).substring((m*3),(m*3)+3)) + .9);
TO
tempx = parseInt(((fpssArray[i][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]

A quick P.P.S.

Having the line like the following:
tempx = parseInt(parseFloat(((fpssArray[i]
[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[i]
[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[i][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]

On Aug 19, 6:48*pm, lorlarz <[e-mail]:

A quick P.P.S.

Having the line like the following:
tempx = parseInt(parseFloat(((fpssArray[i]
[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[i]
[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[i][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[i]
[j]).toString()).substring((m*3),(m*3)+3)) + .9);

line:

Paste in Sample scoring system:
http://mynichecomputing.com/testIntP...mplScoring.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[i][j]).toString()).substring((m*3),
(m*3)+3));

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

Paste in Sample scoring system:
http://mynichecomputing.com/testIntP...mplScoring.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.

[Richard Cornford]

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.

[lorlarz]

On Aug 20, 3:19*am, "Richard Cornford" <[e-mail]>
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[i][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]

On Aug 20, 3:19*am, "Richard Cornford" <[e-mail]>
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.