[R] Interesting quirk with fractions and rounding

Michael Hannon jmhannon.ucdavis at gmail.com
Fri Apr 21 00:34:17 CEST 2017


I might add that things that *look* like integers in R are not really
integers, unless you explicitly label them as such:

> str(20)
 num 20

> str(20.5)
 num 20.5

> str(20L)
 int 20
>

I think that Python 2 will do integer arithmetic on things that look
like integers:

$ python2
.
.
.
>>> 30 / 20
1
>>>

But that behavior has changed in Python 3:

$ python3
.
.
.
>>> 30 / 20
1.5
>>>

-- Mike


On Thu, Apr 20, 2017 at 3:20 PM, Nordlund, Dan (DSHS/RDA)
<NordlDJ at dshs.wa.gov> wrote:
> This is FAQ 7.31.  It is not a bug, it is the unavoidable problem of accurately representing floating point numbers with a finite number of bits of precision.  Look at the following:
>
>> a <- 100*(23/40)
>> b <- (100*23)/40
>> print(a,digits=20)
> [1] 57.499999999999993
>> print(b,digits=20)
> [1] 57.5
>>
>
> Your example with all.equal evaluates TRUE because all.equal uses a 'fuzz factor'.  From the all.equal man page
>
> "all.equal(x, y) is a utility to compare R objects x and y testing 'near equality'."
>
>
> Hope this is helpful,
>
> Dan
>
> Daniel Nordlund, PhD
> Research and Data Analysis Division
> Services & Enterprise Support Administration
> Washington State Department of Social and Health Services
>
>
>> -----Original Message-----
>> From: R-help [mailto:r-help-bounces at r-project.org] On Behalf Of Paul
>> Johnson
>> Sent: Thursday, April 20, 2017 2:56 PM
>> To: R-help
>> 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.
>
> ______________________________________________
> 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.



More information about the R-help mailing list