[R] Interesting quirk with fractions and rounding

Fri Apr 21 18:17:17 CEST 2017

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.