THE integer (or parseInt) inaccuracy all should know about

L

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[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.
 
L

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[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).
 
L

lorlarz

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

lorlarz

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

Lasse Reichstein Nielsen

lorlarz said:
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
 
R

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

lorlarz

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

lorlarz

lorlarz said:
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.

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.


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

lorlarz

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top