459,628 Members | 1,880 Online
Need help? Post your question and get tips & solutions from a community of 459,628 IT Pros & Developers. It's quick & easy.

THE integer (or parseInt) inaccuracy all should know about

 P: n/a 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. Aug 19 '08 #1
6 Replies

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

 P: n/a 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. Aug 19 '08 #3

 P: n/a On Aug 19, 6:48*pm, lorlarz

 P: n/a lorlarz wrote: 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. Aug 20 '08 #5

 P: n/a On Aug 20, 3:19*am, "Richard Cornford" wrote: lorlarz wrote: 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. Aug 20 '08 #6

 P: n/a On Aug 20, 3:19*am, "Richard Cornford" wrote: lorlarz wrote: 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. Aug 20 '08 #7