On Apr 21, 2017 12:01 PM, "JRG" <loesl...@accucom.net> wrote:
A good part of the problem in the specific case you initially presented is that some non-integer numbers have an exact representation in the binary floating point arithmetic being used. Basically, if the fractional part is of the form 1/2^k for some integer k > 0, there is an exact representation in the binary floating point scheme. > options(digits=20) > (100*23)/40 [1] 57.5 > 100*(23/40) [1] 57.499999999999992895 So the two operations give a slightly different result because the fractional part of the division of 100*23 by 40 is 0.5. So the first operations gives, exactly, 57.5 while the second operation does not because 23/40 has no exact representation. Thanks for answering. This case seemed fun because it was not a contrived example. We found this one by comparing masses of report tables from 2 separate programs. It happened 1 time in about 10,000 calculations. Guidelines for R coders, though, would be welcome. So far, all I am sure of is 1 Don't use == for floating point numbers. Your 1/2^k point helps me understand why == does seem to work correctly sometimes. I wonder if we should be suspicious of >=. Imagine the horror if a= w/x > b=y/z in fractions, but digitally a < b. Blech. Can that happen? But, change the example's divisor from 40 to 30 [the fractional part from 1/2 to 2/3]: > (100*23)/30 [1] 76.666666666666671404 > 100*(23/30) [1] 76.666666666666671404 Now the two operations give the same answer to the full precision available. So, it isn't "generally true true in R that (100*x)/y is more accurate than 100*(x/y), if x > y." The good news here is that round() gives same answer in both cases:) I am looking for a case where the first method is less accurate than the second. I expect that multiplying integers before dividing is never less accurate. Sometimes it is more accurate. ` Following your 1/2^k insight, you see why multiplying first is helpful in some cases. Question is will situation get worse. But Bert is right. I have to read more books. I studied Golub and van Loan and came away with healthy fear of matrix inversion. But when you look at user contributed regression packages, what do you find? Matrix inversion and lots of X'X. Paul Johnson University of Kansask The key (in your example) is a property of the way that floating point arithmetic is implemented. ---JRG On 04/21/2017 08:19 AM, Paul Johnson wrote: > We all agree it is a problem with digital computing, not unique to R. I > don't think that is the right place to stop. > > What to do? The round example arose in a real funded project where 2 R > programs differed in results and cause was that one person got 57 and > another got 58. The explanation was found, but its less clear how to > prevent similar in future. Guidelines, anyone? > > So far, these are my guidelines. > > 1. Insert L on numbers to signal that you really mean INTEGER. In R, > forgetting the L in a single number will usually promote whole calculation > to floats. > 2. S3 variables are called 'numeric' if they are integer or double storage. > So avoid "is.numeric" and prefer "is.double". > 3. == is a total fail on floats > 4. Run print with digits=20 so we can see the less rounded number. Perhaps > start sessions with "options(digits=20)" > 5. all.equal does what it promises, but one must be cautious. > > Are there math habits we should follow? > > For example, Is it generally true in R that (100*x)/y is more accurate than > 100*(x/y), if x > y? (If that is generally true, couldn't the R > interpreter do it for the user?) > > I've seen this problem before. In later editions of the game theory program > Gambit, extraordinary effort was taken to keep values symbolically as > integers as long as possible. Avoid division until the last steps. Same in > Swarm simulations. Gary Polhill wrote an essay about the Ghost in the > Machine along those lines, showing accidents from trusting floats. > > I wonder now if all uses of > or < with numeric variables are suspect. > > Oh well. If everybody posts their advice, I will write a summary. > > Paul Johnson > University of Kansas > > On Apr 21, 2017 12:02 AM, "PIKAL Petr" <petr.pi...@precheza.cz> wrote: > >> Hi >> >> The problem is that people using Excel or probably other such spreadsheets >> do not encounter this behaviour as Excel silently rounds all your >> calculations and makes approximate comparison without telling it does so. >> Therefore most people usually do not have any knowledge of floating point >> numbers representation. >> >> Cheers >> Petr >> ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. [[alternative HTML version deleted]] ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
