JavaScript does make errors when dealing just with integers

[lorlarz]

Maybe it was clear in your mind, and looking at that mess of code, it's
a messy mind. If that's your attempt at stripping the problem down to a
simple clear example, it falls way short. It shouldn't need lots of
instructions on what to do.

Try googling:javascriptmathinaccuracy

Don't need to do the google. I have already run the experiment I
described
and seen the error many times. I am a righteous scientist and have
proven
my point scientifically. I wonder if Crockford will find time to see
his
error via THE experiment.

 

[lorlarz]

It's not: you're a troll.

*plonk*

This thread is about the experiment I describe. If you are unwilling
to do it,
then get your unscientific butt out of this thread.

Don't let the door hit you in the ass.

 

[Lasse Reichstein Nielsen]

Contrary to what one authority in the JavaScript field says:
JavaScript does make errors when dealing with just with integers.

This authority (Douglas Crockford.) says:
"integer arithmetic in floating point [as JS uses] is exact"

Well, I can prove this is incorrect with this program:
http://mynichecomputing.com/digitallearning/yourOwn.htm

Your example is short of reproducible, since you have not specified
the data we should enter in order to reproduce it.

Nevertheless, I can see that the program divides by 3 at some point.
At that point it is likely to leave integer arithmetic.

I.e., that, e.g. ((10/3)+1)*3 != 13 is expected behavior and does
not contradict the quote above. It is not integer arithmetic, even
though all the constants used are integer, because some of the
arithmetic is performed on non-integers.

Integer arithmetic is exact in Javascript.

....

You will find the count short. This would be disasterous in a voting
machine.

I would expect that to happen, though
http://xkcd.com/463/

/L

 

[Doug Gunnoe]

What's wrong lorlarz? No further comments?

I would expect more from a righteous *coughtrollcough* scientist.

 

[Stevo]

What's wrong lorlarz? No further comments?

I would expect more from a righteous *coughtrollcough* scientist.

He's preparing his nobel prize acceptance speech.

 

[Tim Streater]

Well, if my "colleagues" are unwilling to replicate a clear
experiment, the cautious Javasripter (who knows not enough to
know otherwise) should believe ME and that: Until further
notice all should assume integer addition in Javascript
may need a slight rounding up to be exact.

Good conclusion. By the way, Crockford has been informed of his
serious factual error on the basics. I am sure that must sting.
He knows he has been held to account here.

No he hasn't. Your "experiment" is crap. As has already been said, you
need to reduce it to a *simple* example.

In all the history of science, all the best experiments have been
*simple*.

 

[lorlarz2]

Contrary to what one authority in the JavaScript field says:
JavaScript does make errors when dealing with just with integers.

This authority (Douglas Crockford.) says:
"integer arithmetic in floating point [as JS uses] is exact"

Well, I can prove this is incorrect with this program:
http://mynichecomputing.com/digitallearning/yourOwn.htm

Your example is short of reproducible, since you have not specified
the data we should enter in order to reproduce it.

Nevertheless, I can see that the program divides by 3 at some point.
At that point it is likely to leave integer arithmetic.

I.e., that, e.g. ((10/3)+1)*3 != 13 is expected behavior and does
not contradict the quote above. It is not integer arithmetic, even

You are correct. The way the program is now written, I actually use
parseFloat in getting a number to be used as an array subscript to
look at a scale's answer. That itself would screw things up.

The problem presently is this line:
tempx = parseInt(parseFloat(((fpssArray
[j]).toString()).substring((m*3),(m*3)+3)) + .9);

BUT, now the real strange integer problem THAT *WAS THERE* BEFORE I
DID this
parseFloat thing (and the + .9 thing) is that this,

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

DID NOT WORK.

To reiterate,
I was sure the program showed some integer problem, but NOW the way it
is,
indeed you are correct, one would expect problems.

Again, THE real problem IS (and I had forgotten) is that THIS,
tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
(m*3)+3));
does NOT work.

THis did show an integer problem (or parseInt problem) that there
SHOULDN'T BE.
I am truly
embarrassed for 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 is there is something that shows an
unexpected integer (OR parseInt) problem.

One must change that line, not only omitting the .9 but also
omitting the intermediate parseFloat conversion to see the problem I
saw.

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. 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. I
should
have re-examined the code more closely to recall all that I had done
to make up for the actual unexpected integer problem -- which still,
to this
day, raises a question and is an issue.

 

[Joost Diepenmaat]

(e-mail address removed) writes some stuff

stop changing your from: line you bastard.

*plonk*

*again*

 

[Doug Gunnoe]

He's preparing his nobel prize acceptance speech.

I seriously just lol for real, Stevo.

 

[lorlarz]

I also apologize for inadvertantly using my second email address. I
shall
not do so again.

I do want this following post (quoted below) associated with me, so
forgive
me for responding to it to make it part of my record.:

A repeat hereon. Do not read on, unless you want to read it again.

Contrary to what one authority in the JavaScript field says:
JavaScript does make errors when dealing with just with integers.
This authority (Douglas Crockford.) says:
"integer arithmetic in floating point [as JS uses] is exact"
Well, I can prove this is incorrect with this program:
http://mynichecomputing.com/digitallearning/yourOwn.htm

Your example is short of reproducible, since you have not specified
the data we should enter in order to reproduce it.

Nevertheless, I can see that the program divides by 3 at some point.
At that point it is likely to leave integer arithmetic.

I.e., that, e.g.  ((10/3)+1)*3 != 13  is expected behavior and does
not contradict the quote above. It is not integer arithmetic, even

You are correct.  The way the program is now written, I actually use
parseFloat in getting a number to be used as an array subscript to
look at a scale's answer.  That itself would screw things up.

The problem presently is this line:
tempx = parseInt(parseFloat(((fpssArray
[j]).toString()).substring((m*3),(m*3)+3)) + .9);

BUT, now the real strange integer problem THAT *WAS THERE* BEFORE I
DID this
parseFloat thing (and the + .9 thing) is that this,

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

DID NOT WORK.

To reiterate,
I was sure the program showed some integer problem, but NOW the way it
is,
indeed you are correct, one would expect problems.

Again, THE real problem IS (and I had forgotten) is that THIS,
tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
(m*3)+3));
does NOT work.

THis did show an integer problem (or parseInt problem) that there
SHOULDN'T BE.
 I am truly
embarrassed for 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 is there is something that shows an
unexpected integer (OR parseInt) problem.

One must change that line, not only omitting the .9 but also
omitting the intermediate parseFloat conversion to see the problem I
saw.

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.  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.  I
should
have re-examined the code more closely to recall all that I had done
to make up for the actual unexpected integer problem -- which still,
to this
day, raises a question and is an issue.

/L

- Show quoted text -- Hide quoted text -

- Show quoted text -

 

[lorlarz]

No he hasn't. Your "experiment" is crap. As has already been said, you
need to reduce it to a *simple* example.

In all the history of science, all the best experiments have been
*simple*.- Hide quoted text -

- Show quoted text -

The experiment is simple. But, it sometimes takes a bit of time to
setup the simple experiment and you are grumbling just because you
are
lazy, as I see it. Nothing is complicated here. There is just the
FACT OF AN INTEGER PROBLEM or parseInt problem, that I have provided
adequate documentaion on. Please see the new uncorrupted thread,
called
"THE integer (or parseInt) inaccuracy all should know about"

 

[lorlarz]

Contrary to what one authority in the JavaScript field says:
JavaScript does make errors when dealing with just with integers.

This authority (Douglas Crockford.) says:
"integer arithmetic in floating point [as JS uses] is exact"

Well, I can prove this is incorrect with this program:
http://mynichecomputing.com/digitallearning/yourOwn.htm

Your example is short of reproducible, since you have not specified
the data we should enter in order to reproduce it.

Nevertheless, I can see that the program divides by 3 at some point.
At that point it is likely to leave integer arithmetic.

I.e., that, e.g.  ((10/3)+1)*3 != 13  is expected behavior and does
not contradict the quote above. It is not integer arithmetic, even
though all the constants used are integer, because some of the
arithmetic is performed on non-integers.

Integer arithmetic is exact in Javascript.

...

You will find the count short.  This would be disasterous in a voting
machine.

I would expect that to happen, though
 http://xkcd.com/463/

/L

Thanks to Lasse Reichstein Nielsen for making the first serious
cogent response. Thanks to him, I looked again and accurately
recalled how to alter http://mynichecomputing.com/digitallearning/yourOwn.htm
to produce the unexplained integer or parseInt error. There is one.

I invite and encourage him and others to respond in the new
uncorrupted
thread, "THE integer (or parseInt) inaccuracy all should know about"

I am sorry I did not accurately present the case right away, but
notice that as soon as there was a first serious response, I
presented
the actual problem asap. Perhaps it has happened to you that you
think
you recall a situation and do not double check. That is what
happened.
I do again apologize. I hope you understand and can forgive me.

 

[Richard Cornford]

On Aug 19, 3:53 pm, Lasse Reichstein Nielsen wrote:

Thanks to Lasse Reichstein Nielsen for making the first serious
cogent response. Thanks to him,

It is a pity that you did not read (or understand) all of what he wrote.

I looked again and accurately
recalled how to alter
http://mynichecomputing.com/digitallearning/yourOwn.htm
to produce the unexplained integer or parseInt error.
There is one.

That is very unlikely.

I invite and encourage him and others to respond in the new
uncorrupted thread, "THE integer (or parseInt) inaccuracy all
should know about"

If you wanted to encourage people to try your code you would have proved
the input data that demonstrated the issue rather than referring people
to an incoherent description of how they were expected to create and
format it for themselves.

I am sorry I did not accurately present the case right away,

You may have already spent your credibility, so maybe it does not
matter.

but notice that as soon as there was a first serious response,
I presented the actual problem asap.

Not yet, not until it is not "short of reproducible", which also means
easily reproduced.

If an issue is real it does not need to be teased out of a mass of
convoluted code; it could be demonstrated in a very simple and direct
way. And a programmer who knows what they are doing would easily be able
to do that.

Perhaps it has happened to you that you think
you recall a situation and do not double check. That is
what happened.
I do again apologize. I hope you understand and can forgive me.

You might want to ease back on calling people "script kiddies" and
making out that you are the only person here who knows anything about
browser scripting if you expect to be forgiven for trying to waste so
much of everyone's time.

Richard.

 

[lorlarz]

It is a pity that you did not read (or understand) all of what he wrote.


That is very unlikely.


If you wanted to encourage people to try your code you would have proved
the input data that demonstrated the issue rather than referring people
to an incoherent description of how they were expected to create and
format it for themselves.


You may have already spent your credibility, so maybe it does not
matter.


Not yet, not until it is not "short of reproducible", which also means
easily reproduced.

If an issue is real it does not need to be teased out of a mass of
convoluted code; it could be demonstrated in a very simple and direct
way. And a programmer who knows what they are doing would easily be able
to do that.


You might want to ease back on calling people "script kiddies" and
making out that you are the only person here who knows anything about
browser scripting if you expect to be forgiven for trying to waste so
much of everyone's time.

Richard.

Richard, You lazy bunch of negative pompous lazy windbags will be glad
to see I did
all the work for you.
See the fourth post in the new thread, "THE integer (or parseInt)
inaccuracy all
should know about"

Take five minutes to see the proof.

And, Your're welcome in advance.

 

[lorlarz]

It is a pity that you did not read (or understand) all of what he wrote.

Lasse actually did not point to what was wrong. I corrected his
particular
worry early on in the new thread.

BUT, looking into the first possibly valid concern of the
first serious responder, I DID recall when and the integer error did
in fact
occur.

I inconvenienced this miserable newsgroup only for as long as it took
for there
to be the first credible brain fart.


[snip]

 

[lorlarz]

It is a pity that you did not read (or understand) all of what he wrote.

Lasse actually did not point to specifically what was wrong.
I corrected his
specific worry early on in the new thread,
"THE integer (or parseInt) inaccuracy all should know about".
Lasse did indicate
the kind of thing that would make my demo invalid and that helped.

Looking into the first possibly valid concern of the
first serious responder, I DID recall when and how the integer error
did
in fact occur and that I had done two things to counter it. Fixing
the
demo to go back to the original version, where I really had the
integer
problem, I realized that *indeed* NOTHING BUT INTEGERS WHERE INVOLVED
in
this version of the program and what I was talking about IS indeed a
problem.

I inconvenienced this miserable newsgroup only for as long as it took
for there to be the first credible activity.

I missed nothing in what Lasse said. You can pretend to make
yourself
feel big. But, that is pathetic.

Main thing is, you all have the proof now in that new thread,
"THE integer (or parseInt) inaccuracy all should know about" , fourth
post.

Maybe something other than a quip or a minor brain fart can now be
triggered.




[snip]

 

[Steve Swift]

Without adding on an arbitrary decimal number less than one (I believe
I use .9) ,

Computers use binary. Would you tell us the *precise* value of 0.9 in
binary, please?

 

[Matthias Watermann]

[...]
The problem presently is this line:
tempx = parseInt(parseFloat(((fpssArray
[j]).toString()).substring((m*3),(m*3)+3)) + .9);

I'd suggest to read (and try to understand) the docs of "parseInt()"
especially the meaning (and consequence) of the second (radix) argument.

--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \

 

[The Magpie]

Funny looking integer.

Yeah, I thought that too...

 

[lorlarz]

[...]
The problem presently is this line:
tempx = parseInt(parseFloat(((fpssArray
[j]).toString()).substring((m*3),(m*3)+3)) + .9);

I'd suggest to read (and try to understand) the docs of "parseInt()"
especially the meaning (and consequence) of the second (radix) argument.

--
        Matthias
    /"\
    \ /    ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
     X                           - AGAINST M$ ATTACHMENTS
    / \

True. Adding the "optional" radix (base) argument fixes the problem:
In
http://mynichecomputing.com/testIntProb/testNew.html
change
tempx = parseInt(((fpssArray[j]).toString()).substring((m*3),
(m*3)+3)); TO

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

and the problem seems fixed without the workaround I previously used.

This is verified by Cornford in the other thread on this.

The base is NOT optional 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.