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.pikal at 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 > > -----Original Message----- > From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of Paul > Johnson > Sent: Thursday, April 20, 2017 11:56 PM > To: R-help <r-help at r-project.org> > Subject: [R] Interesting quirk with fractions and rounding > > Hello, R friends > > My student unearthed this quirk that might interest you. > > I wondered if this might be a bug in the R interpreter. If not a bug, it > certainly stands as a good example of the dangers of floating point numbers > in computing. > > What do you think? > > > 100*(23/40) > [1] 57.5 > > (100*23)/40 > [1] 57.5 > > round(100*(23/40)) > [1] 57 > > round((100*23)/40) > [1] 58 > > The result in the 2 rounds should be the same, I think. Clearly some > digital number devil is at work. I *guess* that when you put in whole > numbers and group them like this (100*23), the interpreter does integer > math, but if you group (23/40), you force a fractional division and a > floating point number. The results from the first 2 calculations are not > actually 57.5, they just appear that way. > > Before you close the books, look at this: > > > aa <- 100*(23/40) > > bb <- (100*23)/40 > > all.equal(aa,bb) > [1] TRUE > > round(aa) > [1] 57 > > round(bb) > [1] 58 > > I'm putting this one in my collection of "difficult to understand" > numerical calculations. > > If you have seen this before, I'm sorry to waste your time. > > pj > -- > Paul E. Johnson http://pj.freefaculty.org > Director, Center for Research Methods and Data Analysis > http://crmda.ku.edu > > To write to me directly, please address me at pauljohn at ku.edu. > > ______________________________________________ > R-help at 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. > > ________________________________ > Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a jsou > ur?eny pouze jeho adres?t?m. > Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? > neprodlen? jeho odes?latele. Obsah tohoto emailu i s p??lohami a jeho kopie > vyma?te ze sv?ho syst?mu. > Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento email > jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat. > Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou modifikacemi > ?i zpo?d?n?m p?enosu e-mailu. > > V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?: > - vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? > smlouvy, a to z jak?hokoliv d?vodu i bez uveden? d?vodu. > - a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? p?ijmout; > Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze strany > p??jemce s dodatkem ?i odchylkou. > - trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve > v?slovn?m dosa?en?m shody na v?ech jej?ch n?le?itostech. > - odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za > spole?nost ??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? zmocn?n > nebo p?semn? pov??en a takov? pov??en? nebo pln? moc byly adres?tovi tohoto > emailu p??padn? osob?, kterou adres?t zastupuje, p?edlo?eny nebo jejich > existence je adres?tovi ?i osob? j?m zastoupen? zn?m?. > > This e-mail and any documents attached to it may be confidential and are > intended only for its intended recipients. > If you received this e-mail by mistake, please immediately inform its > sender. Delete the contents of this e-mail with all attachments and its > copies from your system. > If you are not the intended recipient of this e-mail, you are not > authorized to use, disseminate, copy or disclose this e-mail in any manner. > The sender of this e-mail shall not be liable for any possible damage > caused by modifications of the e-mail or by delay with transfer of the > email. > > In case that this e-mail forms part of business dealings: > - the sender reserves the right to end negotiations about entering into a > contract in any time, for any reason, and without stating any reasoning. > - if the e-mail contains an offer, the recipient is entitled to > immediately accept such offer; The sender of this e-mail (offer) excludes > any acceptance of the offer on the part of the recipient containing any > amendment or variation. > - the sender insists on that the respective contract is concluded only > upon an express mutual agreement on all its aspects. > - the sender of this e-mail informs that he/she is not authorized to enter > into any contracts on behalf of the company except for cases in which > he/she is expressly authorized to do so in writing, and such authorization > or power of attorney is submitted to the recipient or the person > represented by the recipient, or the existence of such authorization is > known to the recipient of the person represented by the recipient. >[[alternative HTML version deleted]]
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. 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 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.pikal at 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 >> >> -----Original Message----- >> From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of Paul >> Johnson >> Sent: Thursday, April 20, 2017 11:56 PM >> To: R-help <r-help at r-project.org> >> Subject: [R] Interesting quirk with fractions and rounding >> >> Hello, R friends >> >> My student unearthed this quirk that might interest you. >> >> I wondered if this might be a bug in the R interpreter. If not a bug, it >> certainly stands as a good example of the dangers of floating point numbers >> in computing. >> >> What do you think? >> >>> 100*(23/40) >> [1] 57.5 >>> (100*23)/40 >> [1] 57.5 >>> round(100*(23/40)) >> [1] 57 >>> round((100*23)/40) >> [1] 58 >> >> The result in the 2 rounds should be the same, I think. Clearly some >> digital number devil is at work. I *guess* that when you put in whole >> numbers and group them like this (100*23), the interpreter does integer >> math, but if you group (23/40), you force a fractional division and a >> floating point number. The results from the first 2 calculations are not >> actually 57.5, they just appear that way. >> >> Before you close the books, look at this: >> >>> aa <- 100*(23/40) >>> bb <- (100*23)/40 >>> all.equal(aa,bb) >> [1] TRUE >>> round(aa) >> [1] 57 >>> round(bb) >> [1] 58 >> >> I'm putting this one in my collection of "difficult to understand" >> numerical calculations. >> >> If you have seen this before, I'm sorry to waste your time. >> >> pj >> -- >> Paul E. Johnson http://pj.freefaculty.org >> Director, Center for Research Methods and Data Analysis >> http://crmda.ku.edu >> >> To write to me directly, please address me at pauljohn at ku.edu. >> >> ______________________________________________ >> R-help at 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. >> >> ________________________________ >> Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a jsou >> ur?eny pouze jeho adres?t?m. >> Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? >> neprodlen? jeho odes?latele. Obsah tohoto emailu i s p??lohami a jeho kopie >> vyma?te ze sv?ho syst?mu. >> Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento email >> jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat. >> Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou modifikacemi >> ?i zpo?d?n?m p?enosu e-mailu. >> >> V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?: >> - vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? >> smlouvy, a to z jak?hokoliv d?vodu i bez uveden? d?vodu. >> - a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? p?ijmout; >> Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze strany >> p??jemce s dodatkem ?i odchylkou. >> - trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve >> v?slovn?m dosa?en?m shody na v?ech jej?ch n?le?itostech. >> - odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za >> spole?nost ??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? zmocn?n >> nebo p?semn? pov??en a takov? pov??en? nebo pln? moc byly adres?tovi tohoto >> emailu p??padn? osob?, kterou adres?t zastupuje, p?edlo?eny nebo jejich >> existence je adres?tovi ?i osob? j?m zastoupen? zn?m?. >> >> This e-mail and any documents attached to it may be confidential and are >> intended only for its intended recipients. >> If you received this e-mail by mistake, please immediately inform its >> sender. Delete the contents of this e-mail with all attachments and its >> copies from your system. >> If you are not the intended recipient of this e-mail, you are not >> authorized to use, disseminate, copy or disclose this e-mail in any manner. >> The sender of this e-mail shall not be liable for any possible damage >> caused by modifications of the e-mail or by delay with transfer of the >> email. >> >> In case that this e-mail forms part of business dealings: >> - the sender reserves the right to end negotiations about entering into a >> contract in any time, for any reason, and without stating any reasoning. >> - if the e-mail contains an offer, the recipient is entitled to >> immediately accept such offer; The sender of this e-mail (offer) excludes >> any acceptance of the offer on the part of the recipient containing any >> amendment or variation. >> - the sender insists on that the respective contract is concluded only >> upon an express mutual agreement on all its aspects. >> - the sender of this e-mail informs that he/she is not authorized to enter >> into any contracts on behalf of the company except for cases in which >> he/she is expressly authorized to do so in writing, and such authorization >> or power of attorney is submitted to the recipient or the person >> represented by the recipient, or the existence of such authorization is >> known to the recipient of the person represented by the recipient. >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at 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. >
I suggest you read some basic books on numerical analysis and/or talk with a numerical analyst. You are (like most of us) an amateur at this sort of thing trying to reinvent wheels. If you are concerned with details, talk with experts. Don't assume what you don't know. This list is *not* a reliable source of such expertise, although there *are* individuals in the R universe with considerable knowledge who may or may not choose to respond. Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Fri, Apr 21, 2017 at 5:19 AM, Paul Johnson <pauljohn32 at gmail.com> 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.pikal at 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 >> >> -----Original Message----- >> From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of Paul >> Johnson >> Sent: Thursday, April 20, 2017 11:56 PM >> To: R-help <r-help at r-project.org> >> Subject: [R] Interesting quirk with fractions and rounding >> >> Hello, R friends >> >> My student unearthed this quirk that might interest you. >> >> I wondered if this might be a bug in the R interpreter. If not a bug, it >> certainly stands as a good example of the dangers of floating point numbers >> in computing. >> >> What do you think? >> >> > 100*(23/40) >> [1] 57.5 >> > (100*23)/40 >> [1] 57.5 >> > round(100*(23/40)) >> [1] 57 >> > round((100*23)/40) >> [1] 58 >> >> The result in the 2 rounds should be the same, I think. Clearly some >> digital number devil is at work. I *guess* that when you put in whole >> numbers and group them like this (100*23), the interpreter does integer >> math, but if you group (23/40), you force a fractional division and a >> floating point number. The results from the first 2 calculations are not >> actually 57.5, they just appear that way. >> >> Before you close the books, look at this: >> >> > aa <- 100*(23/40) >> > bb <- (100*23)/40 >> > all.equal(aa,bb) >> [1] TRUE >> > round(aa) >> [1] 57 >> > round(bb) >> [1] 58 >> >> I'm putting this one in my collection of "difficult to understand" >> numerical calculations. >> >> If you have seen this before, I'm sorry to waste your time. >> >> pj >> -- >> Paul E. Johnson http://pj.freefaculty.org >> Director, Center for Research Methods and Data Analysis >> http://crmda.ku.edu >> >> To write to me directly, please address me at pauljohn at ku.edu. >> >> ______________________________________________ >> R-help at 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. >> >> ________________________________ >> Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a jsou >> ur?eny pouze jeho adres?t?m. >> Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? >> neprodlen? jeho odes?latele. Obsah tohoto emailu i s p??lohami a jeho kopie >> vyma?te ze sv?ho syst?mu. >> Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento email >> jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat. >> Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou modifikacemi >> ?i zpo?d?n?m p?enosu e-mailu. >> >> V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?: >> - vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? >> smlouvy, a to z jak?hokoliv d?vodu i bez uveden? d?vodu. >> - a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? p?ijmout; >> Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze strany >> p??jemce s dodatkem ?i odchylkou. >> - trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve >> v?slovn?m dosa?en?m shody na v?ech jej?ch n?le?itostech. >> - odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za >> spole?nost ??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? zmocn?n >> nebo p?semn? pov??en a takov? pov??en? nebo pln? moc byly adres?tovi tohoto >> emailu p??padn? osob?, kterou adres?t zastupuje, p?edlo?eny nebo jejich >> existence je adres?tovi ?i osob? j?m zastoupen? zn?m?. >> >> This e-mail and any documents attached to it may be confidential and are >> intended only for its intended recipients. >> If you received this e-mail by mistake, please immediately inform its >> sender. Delete the contents of this e-mail with all attachments and its >> copies from your system. >> If you are not the intended recipient of this e-mail, you are not >> authorized to use, disseminate, copy or disclose this e-mail in any manner. >> The sender of this e-mail shall not be liable for any possible damage >> caused by modifications of the e-mail or by delay with transfer of the >> email. >> >> In case that this e-mail forms part of business dealings: >> - the sender reserves the right to end negotiations about entering into a >> contract in any time, for any reason, and without stating any reasoning. >> - if the e-mail contains an offer, the recipient is entitled to >> immediately accept such offer; The sender of this e-mail (offer) excludes >> any acceptance of the offer on the part of the recipient containing any >> amendment or variation. >> - the sender insists on that the respective contract is concluded only >> upon an express mutual agreement on all its aspects. >> - the sender of this e-mail informs that he/she is not authorized to enter >> into any contracts on behalf of the company except for cases in which >> he/she is expressly authorized to do so in writing, and such authorization >> or power of attorney is submitted to the recipient or the person >> represented by the recipient, or the existence of such authorization is >> known to the recipient of the person represented by the recipient. >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at 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.
Your guideline #1 is invalid for R... compare 5L/3L to 5L %/% 3L. If you want to avoid automatic conversion to double then you have to be cautious which operators/functions you apply to them... merely throwing in L everywhere is not going to help. #2 refers to S3, but that is a completely different concept. I am not sure why you think you should "prefer is.double", since is.numeric is perfectly useful for everyday analysis. I think that numbers that represent input data can be numeric (either integer or double) but should be treated as though they were always approximate. That means don't spend time printing them out with 20 digits of precision except for illustration... just always assume that they could be slightly different than they look when printed. Which means (for example) that you have to be cautious about whether you want to ROUND or TRUNCATE when binning. If you do this you will stop feeling surprised by this kind of result. Of all groups of people who have to deal with floating point numbers, shouldn't statisticians be able to work effectively with approximate values? Numbers that represent internally-generated indexes and factors should be created as and treated like integers. All you have to do is remember which of these two categories each numeric vector has and you will tend to avoid abusing them and being surprised by the results. I don't think (100*x)/y is necessarily more accurate than 100*(x/y)... they just have different approximations in some cases. Each sub-expression has the same number of bits in the mantissa, so the uncertainty propagates the same in both cases. Of more concern is things like c1+c2*x+c3*x*x versus c1+x*(c2+c3*x), but these are numerical analysis concerns for which there are whole courses to explain the issue, and are not specific to R or on-topic here. -- Sent from my phone. Please excuse my brevity. On April 21, 2017 5:19:10 AM PDT, Paul Johnson <pauljohn32 at gmail.com> 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.pikal at 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 >> >> -----Original Message----- >> From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of Paul >> Johnson >> Sent: Thursday, April 20, 2017 11:56 PM >> To: R-help <r-help at r-project.org> >> Subject: [R] Interesting quirk with fractions and rounding >> >> Hello, R friends >> >> My student unearthed this quirk that might interest you. >> >> I wondered if this might be a bug in the R interpreter. If not a bug, >it >> certainly stands as a good example of the dangers of floating point >numbers >> in computing. >> >> What do you think? >> >> > 100*(23/40) >> [1] 57.5 >> > (100*23)/40 >> [1] 57.5 >> > round(100*(23/40)) >> [1] 57 >> > round((100*23)/40) >> [1] 58 >> >> The result in the 2 rounds should be the same, I think. Clearly some >> digital number devil is at work. I *guess* that when you put in whole >> numbers and group them like this (100*23), the interpreter does >integer >> math, but if you group (23/40), you force a fractional division and a >> floating point number. The results from the first 2 calculations are >not >> actually 57.5, they just appear that way. >> >> Before you close the books, look at this: >> >> > aa <- 100*(23/40) >> > bb <- (100*23)/40 >> > all.equal(aa,bb) >> [1] TRUE >> > round(aa) >> [1] 57 >> > round(bb) >> [1] 58 >> >> I'm putting this one in my collection of "difficult to understand" >> numerical calculations. >> >> If you have seen this before, I'm sorry to waste your time. >> >> pj >> -- >> Paul E. Johnson http://pj.freefaculty.org >> Director, Center for Research Methods and Data Analysis >> http://crmda.ku.edu >> >> To write to me directly, please address me at pauljohn at ku.edu. >> >> ______________________________________________ >> R-help at 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. >> >> ________________________________ >> Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a >jsou >> ur?eny pouze jeho adres?t?m. >> Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? >> neprodlen? jeho odes?latele. Obsah tohoto emailu i s p??lohami a jeho >kopie >> vyma?te ze sv?ho syst?mu. >> Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento >email >> jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat. >> Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou >modifikacemi >> ?i zpo?d?n?m p?enosu e-mailu. >> >> V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?: >> - vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? >> smlouvy, a to z jak?hokoliv d?vodu i bez uveden? d?vodu. >> - a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? >p?ijmout; >> Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze >strany >> p??jemce s dodatkem ?i odchylkou. >> - trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve >> v?slovn?m dosa?en?m shody na v?ech jej?ch n?le?itostech. >> - odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za >> spole?nost ??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? >zmocn?n >> nebo p?semn? pov??en a takov? pov??en? nebo pln? moc byly adres?tovi >tohoto >> emailu p??padn? osob?, kterou adres?t zastupuje, p?edlo?eny nebo >jejich >> existence je adres?tovi ?i osob? j?m zastoupen? zn?m?. >> >> This e-mail and any documents attached to it may be confidential and >are >> intended only for its intended recipients. >> If you received this e-mail by mistake, please immediately inform its >> sender. Delete the contents of this e-mail with all attachments and >its >> copies from your system. >> If you are not the intended recipient of this e-mail, you are not >> authorized to use, disseminate, copy or disclose this e-mail in any >manner. >> The sender of this e-mail shall not be liable for any possible damage >> caused by modifications of the e-mail or by delay with transfer of >the >> email. >> >> In case that this e-mail forms part of business dealings: >> - the sender reserves the right to end negotiations about entering >into a >> contract in any time, for any reason, and without stating any >reasoning. >> - if the e-mail contains an offer, the recipient is entitled to >> immediately accept such offer; The sender of this e-mail (offer) >excludes >> any acceptance of the offer on the part of the recipient containing >any >> amendment or variation. >> - the sender insists on that the respective contract is concluded >only >> upon an express mutual agreement on all its aspects. >> - the sender of this e-mail informs that he/she is not authorized to >enter >> into any contracts on behalf of the company except for cases in which >> he/she is expressly authorized to do so in writing, and such >authorization >> or power of attorney is submitted to the recipient or the person >> represented by the recipient, or the existence of such authorization >is >> known to the recipient of the person represented by the recipient. >> > > [[alternative HTML version deleted]] > >______________________________________________ >R-help at 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.
On 04/21/2017 05: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?Note that the error is amplified by the use of round() at the end of the calculation. Whoever wrote that code should know that by doing this the result will possibly differ by 1 across users. So, ideally, s/he should document this in his/her function to minimize the "surprise effect" on the user side. Another option is to not round() the final result and leave that responsibility to the end user. That's what I would do. H.> > 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.pikal at 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 >> >> -----Original Message----- >> From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of Paul >> Johnson >> Sent: Thursday, April 20, 2017 11:56 PM >> To: R-help <r-help at r-project.org> >> Subject: [R] Interesting quirk with fractions and rounding >> >> Hello, R friends >> >> My student unearthed this quirk that might interest you. >> >> I wondered if this might be a bug in the R interpreter. If not a bug, it >> certainly stands as a good example of the dangers of floating point numbers >> in computing. >> >> What do you think? >> >>> 100*(23/40) >> [1] 57.5 >>> (100*23)/40 >> [1] 57.5 >>> round(100*(23/40)) >> [1] 57 >>> round((100*23)/40) >> [1] 58 >> >> The result in the 2 rounds should be the same, I think. Clearly some >> digital number devil is at work. I *guess* that when you put in whole >> numbers and group them like this (100*23), the interpreter does integer >> math, but if you group (23/40), you force a fractional division and a >> floating point number. The results from the first 2 calculations are not >> actually 57.5, they just appear that way. >> >> Before you close the books, look at this: >> >>> aa <- 100*(23/40) >>> bb <- (100*23)/40 >>> all.equal(aa,bb) >> [1] TRUE >>> round(aa) >> [1] 57 >>> round(bb) >> [1] 58 >> >> I'm putting this one in my collection of "difficult to understand" >> numerical calculations. >> >> If you have seen this before, I'm sorry to waste your time. >> >> pj >> -- >> Paul E. Johnson https://urldefense.proofpoint.com/v2/url?u=http-3A__pj.freefaculty.org&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=1JaAU8JTsAs-1eiwcWXgFMF6An1cjDHTSOjin674VRk&s=iJyBC6GWjCxIv2vLzCBFL9KSP7jdm7aNxv00SLVJ7P0&e>> Director, Center for Research Methods and Data Analysis >> https://urldefense.proofpoint.com/v2/url?u=http-3A__crmda.ku.edu&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=1JaAU8JTsAs-1eiwcWXgFMF6An1cjDHTSOjin674VRk&s=enQ7hFGHB0hmVSmc-Ey3B_421i62QzFsaiN8faqRiSc&e>> >> To write to me directly, please address me at pauljohn at ku.edu. >> >> ______________________________________________ >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dhelp&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=1JaAU8JTsAs-1eiwcWXgFMF6An1cjDHTSOjin674VRk&s=lhpXJFzjB4p_pEFeUijjWa8Xd7IQ9ZOIzh5grUd7DQg&e>> PLEASE do read the posting guide https://urldefense.proofpoint.com/v2/url?u=http-3A__www.R-2Dproject.org_&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=1JaAU8JTsAs-1eiwcWXgFMF6An1cjDHTSOjin674VRk&s=ekbaqk4VTBEMyCFXosKWt561I1fiM0OVZDw5p8spUaI&e>> posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> >> ________________________________ >> Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a jsou >> ur?eny pouze jeho adres?t?m. >> Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? >> neprodlen? jeho odes?latele. Obsah tohoto emailu i s p??lohami a jeho kopie >> vyma?te ze sv?ho syst?mu. >> Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento email >> jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat. >> Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou modifikacemi >> ?i zpo?d?n?m p?enosu e-mailu. >> >> V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?: >> - vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? >> smlouvy, a to z jak?hokoliv d?vodu i bez uveden? d?vodu. >> - a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? p?ijmout; >> Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze strany >> p??jemce s dodatkem ?i odchylkou. >> - trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve >> v?slovn?m dosa?en?m shody na v?ech jej?ch n?le?itostech. >> - odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za >> spole?nost ??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? zmocn?n >> nebo p?semn? pov??en a takov? pov??en? nebo pln? moc byly adres?tovi tohoto >> emailu p??padn? osob?, kterou adres?t zastupuje, p?edlo?eny nebo jejich >> existence je adres?tovi ?i osob? j?m zastoupen? zn?m?. >> >> This e-mail and any documents attached to it may be confidential and are >> intended only for its intended recipients. >> If you received this e-mail by mistake, please immediately inform its >> sender. Delete the contents of this e-mail with all attachments and its >> copies from your system. >> If you are not the intended recipient of this e-mail, you are not >> authorized to use, disseminate, copy or disclose this e-mail in any manner. >> The sender of this e-mail shall not be liable for any possible damage >> caused by modifications of the e-mail or by delay with transfer of the >> email. >> >> In case that this e-mail forms part of business dealings: >> - the sender reserves the right to end negotiations about entering into a >> contract in any time, for any reason, and without stating any reasoning. >> - if the e-mail contains an offer, the recipient is entitled to >> immediately accept such offer; The sender of this e-mail (offer) excludes >> any acceptance of the offer on the part of the recipient containing any >> amendment or variation. >> - the sender insists on that the respective contract is concluded only >> upon an express mutual agreement on all its aspects. >> - the sender of this e-mail informs that he/she is not authorized to enter >> into any contracts on behalf of the company except for cases in which >> he/she is expressly authorized to do so in writing, and such authorization >> or power of attorney is submitted to the recipient or the person >> represented by the recipient, or the existence of such authorization is >> known to the recipient of the person represented by the recipient. >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dhelp&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=1JaAU8JTsAs-1eiwcWXgFMF6An1cjDHTSOjin674VRk&s=lhpXJFzjB4p_pEFeUijjWa8Xd7IQ9ZOIzh5grUd7DQg&e> PLEASE do read the posting guide https://urldefense.proofpoint.com/v2/url?u=http-3A__www.R-2Dproject.org_posting-2Dguide.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=1JaAU8JTsAs-1eiwcWXgFMF6An1cjDHTSOjin674VRk&s=Gg8ShT8jT0TS19y42_4tYW23RMUgqeewiCRAW-TbXT0&e> and provide commented, minimal, self-contained, reproducible code. >-- Herv? Pag?s Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319
I've been following this thread with interest. A nice
collection of things to watch out for, if you don't
want the small arithmetic errors due to finite-length
digital representations of fractions to cause trouble!
However, as well as these small discrepancies, major
malfunctions can also result.
Back on Dec 22, 2013, I posted a Christmas Greetings
message to R-help:
Season's Greetings (and great news ... )!
which starts:
Greetings All!
With the Festive Season fast approaching, I bring you joy
with the news (which you will surely wish to celebrate)
that R cannot do arithmetic!
Usually, this is manifest in a trivial way when users report
puzzlement that, for instance,
sqrt(pi)^2 == pi
# [1] FALSE
which is the result of a (generally trivial) rounding or
truncation error:
sqrt(pi)^2 - pi
# [1] -4.440892e-16
But for some very simple calculations R goes off its head.
And the example given is:
Consider a sequence generated by the recurrence relation
x[n+1] = 2*x[n] if 0 <= x[n] <= 1/2
x[n+1] = 2*(1 - x[n]) if 1/2 < x[n] <= 1
(for 0 <= x[n] <= 1).
This has equilibrium points (x[n+1] = x[n]) at x[n] = 0
and at x[n] = 2/3:
2/3 -> 2*(1 - 2/3) = 2/3
It also has periodic points, e.g.
2/5 -> 4/5 -> 2/5 (period 2)
2/9 -> 4/9 -> 8/9 -> 2/9 (period 3)
The recurrence relation can be implemented as the R function
nextx <- function(x){
if( (0<=x)&(x<=1/2) ) {x <- 2*x} else {x <- 2*(1 - x)}
}
Now have a look at what happens when we start at the equilibrium
point x = 2/3:
N <- 1 ; x <- 2/3
while(x > 0){
cat(sprintf("%i: %.9f\n",N,x))
x <- nextx(x) ; N <- N+1
}
cat(sprintf("%i: %.9f\n",N,x))
For a while [run it and see!], this looks as though it's doing what
the arithmetic would lead us to expect: the first 24 results will all
be printed as 0.666666667, which looks fine as 2/3 to 9 places.
But then the "little errors" start to creep in:
N=25: 0.666666666
N=28: 0.666666672
N=46: 0.667968750
N=47: 0.664062500
N=48: 0.671875000
N=49: 0.656250000
N=50: 0.687500000
N=51: 0.625000000
N=52: 0.750000000
N=53: 0.500000000
N=54: 1.000000000
N=55: 0.000000000
What is happening is that, each time R multiplies by 2, the binary
representation is shifted up by one and a zero bit is introduced
at the bottom end.
At N=53, the first binary bit of 'x' is 1, and all the rest are 0,
so now 'x' is exactly 0.5 = 1/2, hence the final two are also exact
results; 53 is the Machine$double.digits = 53 binary places.
So this normally "almost" trivial feature can, for such a simple
calculation, lead to chaos or catastrophe (in the literal technical
sense).
For more detail, including an extension of the above, look at the
original posting in the R-help archives for Dec 22, 2013:
From: (Ted Harding) <Ted.Harding at wlandres.net>
Subject: [R] Season's Greetings (and great news ... )!
Date: Sun, 22 Dec 2013 09:59:16 -0000 (GMT)
(Apologies, but I couldn't track down the URL for this posting
in the R-help archives; there were a few follow-ups).
I gave this as an example to show that the results of the "little"
arithmetic errors (such as have recently been discussed from many
aspects) can, in certain contexts, destroy a computation.
So be careful to consider what can happen in the particular
context you are working with.
There are ways to dodge the issue -- such as using the R interface
to the 'bc' calculator, which computes arithmetic expressions in
a way which is quite different from the fixed-finite-length binary
representation and algorithms used, not only by R, but also by many
other numerical computation software suites
Best wishes to all,
Ted.
-------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at wlandres.net>
Date: 21-Apr-2017 Time: 22:03:15
This message was sent by XFMail
On Apr 21, 2017 12:01 PM, "JRG" <loesljrg at 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 doublestorage.> 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 accuratethan> 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 theoryprogram> 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.pikal at precheza.cz> wrote: > >> Hi >> >> The problem is that people using Excel or probably other suchspreadsheets>> 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 at 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]]