Velocity Reviews > THE integer (or parseInt) inaccuracy all should know about

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

lorlarz
Guest
Posts: n/a

 08-19-2008
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
(as described). Sorry.

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

lorlarz
Guest
Posts: n/a

 08-19-2008
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 Removed)> 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[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
> (as described). *Sorry.
>
> In summary:
> There is an integer (or parseInt) problem which needs to be known
> I had forgotten 2 changes were involved in fixing the problem. *How
> to
> recreate the problem has now been clearly indicated.

lorlarz
Guest
Posts: n/a

 08-19-2008
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).

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
Guest
Posts: n/a

 08-20-2008
On Aug 19, 6:48*pm, lorlarz <(E-Mail Removed)> wrote:
> 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).
>
> 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.

Lasse Reichstein Nielsen
Guest
Posts: n/a

 08-20-2008
lorlarz <(E-Mail Removed)> 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[i][j]).toString()).substring((m*3),
> (m*3)+3));
> does NOT work.

Could you tell us:
1. What the value if fpssArray[i][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
> (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
> 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.'

Richard Cornford
Guest
Posts: n/a

 08-20-2008
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
Guest
Posts: n/a

 08-20-2008
On Aug 20, 3:19*am, "Richard Cornford" <(E-Mail Removed)>
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.

lorlarz
Guest
Posts: n/a

 08-20-2008
On Aug 20, 12:13*am, Lasse Reichstein Nielsen <(E-Mail Removed)> wrote:
> lorlarz <(E-Mail Removed)> 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[i][j]).toString()).substring((m*3),
> > (m*3)+3));
> > does NOT work.

>
> Could you tell us:
> 1. What the value if fpssArray[i][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
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
> > (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

>
> > In summary:
> > There is an integer (or parseInt) problem which needs to be known
> > 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
Guest
Posts: n/a

 08-20-2008
On Aug 20, 3:19*am, "Richard Cornford" <(E-Mail Removed)>
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
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.