Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > JavaScript does make errors when dealing just with integers

Reply
Thread Tools

JavaScript does make errors when dealing just with integers

 
 
lorlarz
Guest
Posts: n/a
 
      08-19-2008
On Aug 19, 3:10*pm, Stevo <(E-Mail Removed)> wrote:
> lorlarz wrote:
> > Since I laid down the challenge and it was clear

>
> 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.
 
Reply With Quote
 
 
 
 
lorlarz
Guest
Posts: n/a
 
      08-19-2008
On Aug 19, 3:13*pm, Joost Diepenmaat <(E-Mail Removed)> wrote:
> lorlarz <(E-Mail Removed)> writes:
> > Hard to really label a person a troll who is talking about a
> > particular claim
> > about a particular experiment in computer science (but that seems to
> > escape
> > your "sensibilities").

>
> It's not: you're a troll.
>
> *plonk*
>
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/


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.
 
Reply With Quote
 
 
 
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      08-19-2008
lorlarz <(E-Mail Removed)> writes:

> 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
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
Doug Gunnoe
Guest
Posts: n/a
 
      08-19-2008
What's wrong lorlarz? No further comments?

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

 
Reply With Quote
 
Stevo
Guest
Posts: n/a
 
      08-19-2008
Doug Gunnoe wrote:
> What's wrong lorlarz? No further comments?
>
> I would expect more from a righteous *coughtrollcough* scientist.


He's preparing his nobel prize acceptance speech.
 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      08-19-2008
In article
<(E-Mail Removed)>,
lorlarz <(E-Mail Removed)> wrote:

> On Aug 19, 3:00*pm, Joost Diepenmaat <(E-Mail Removed)> wrote:
> > lorlarz <(E-Mail Removed)> writes:
> > > Since I laid down the challenge and it was clear and it was not any
> > > more
> > > or less than any scientist would want, I assume this means you bow to
> > > my
> > > expertise and opinion (by the default of being too lazy to conduct a
> > > test).

> >
> > See (again):
> >
> > http://www.catb.org/~esr/faqs/smart-....html#id306810
> >
> > > Until further notice all should assume integer addition in Javascript
> > > my need
> > > a slight rounding up to be exact.

> >
> > That's the stupidest conclusion I've seen you draw all day. You really
> > should spend less time messing about with the DOM and more time
> > learning about actual programming.
> >
> > --
> > Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

>
> 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*.
 
Reply With Quote
 
lorlarz2@gmail.com
Guest
Posts: n/a
 
      08-19-2008
On Aug 19, 3:53 pm, Lasse Reichstein Nielsen <(E-Mail Removed)> wrote:
> lorlarz <(E-Mail Removed)> writes:
> > 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[i]
[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[i][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[i][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[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. 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
> --
> Lasse Reichstein Nielsen
> DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
> 'Faith without judgement merely degrades the spirit divine.'

 
Reply With Quote
 
Joost Diepenmaat
Guest
Posts: n/a
 
      08-19-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) writes some stuff

stop changing your from: line you bastard.

*plonk*

*again*

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
 
Reply With Quote
 
Doug Gunnoe
Guest
Posts: n/a
 
      08-19-2008
On Aug 19, 5:07*pm, Stevo <(E-Mail Removed)> wrote:
> Doug Gunnoe wrote:
> > What's wrong lorlarz? No further comments?

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

>
> He's preparing his nobel prize acceptance speech.


I seriously just lol for real, Stevo.
 
Reply With Quote
 
lorlarz
Guest
Posts: n/a
 
      08-19-2008
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.

On Aug 19, 5:30*pm, (E-Mail Removed) wrote:
> On Aug 19, 3:53 pm, Lasse Reichstein Nielsen <(E-Mail Removed)> wrote:
>
>
>
>
>
> > lorlarz <(E-Mail Removed)> writes:
> > > 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[i]
> [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[i][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[i][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[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. *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
> > --
> > Lasse Reichstein Nielsen
> > *DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
> > * 'Faith without judgement merely degrades the spirit divine.'- Hide quoted text -

>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to avoid Out of Memory Errors when dealing with a large XML file? Saqib Ali Perl Misc 2 01-14-2011 09:31 PM
Subprocess module - communicate(data) dealing with errors Paul Moore Python 0 11-21-2006 10:51 PM
When exceptions aren't enough: Dealing with runtime errors. Aaron W. LaFramboise C++ 4 07-25-2005 04:58 AM
Errors, errors, errors Mark Goldin ASP .Net 2 01-17-2004 08:05 PM
Tips for Dealing with "Just Taylor's" SPAM Anonymous Computer Support 1 07-14-2003 03:45 PM



Advertisments