This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why are these numbers not equal?
Can anyone explain to me, why R answers FALSE in the following case?
(1-0.9)>=0.1
How can I get TRUE for comparisons of that kind?
This has to do with floating point precision. There is in essence an infinite amount of floating points, do representing them in the computer can only be done discretely, and thus with limited precision. To take this limited precision into account, use all.equal to make the comparison. As #RomainFracois said, this is very frequently asked question in R.
This is the classic R FAQ 7.31. You need all.equal
You could create your own binary operators to do what you're after and store them in your .Rprofile:
`%>=%` <- function(x, y) all.equal(x, y) | x > y
`%<=%` <- function(x, y) all.equal(x, y) | x < y
c(1-.9)>=.1
c(1-.9)%>=% .1
Related
This question already has answers here:
Why are these numbers not equal?
(6 answers)
Closed 2 years ago.
I came across a strange thing in R programming. When I simulate a sequence and want to judge whether the element is less than 0.5,
t=(1:1440)/1440
x=(t[720]-t[648])/0.1
x
#output:[1] 0.5
x<1/2
#output:[1] TRUE
x=0.5
x<1/2
#output:[1] FALSE
The two results are completely opposite and obviously the second result is what I want. Can anybody help me?
Floating point arithmetic is not exact in R, and the value you expect to be numerically exact to 0.5 may in fact be slightly more (or less). One possible workaround here would be to use rounding:
t <- (1:1440)/1440
x <- (t[720]-t[648]) / 0.1
round(x, 1) < 0.5
This question already has answers here:
how to calculate reverse modulus
(5 answers)
Closed 5 years ago.
If I have an equation like (x+c) mod y = z and I need to solve for y, how would I go about doing that?
Apologies if this is more math than programming.
No simple formula exists. If a mod n = r then n divides a-r and 0 <= r < n. Candidate n can be found by factoring a - r and finding divisors which are larger than r. Factoring is a much-studied but non-trivial problem. Pick your favorite factoring algorithm. Unless a-r is prime, there won't be a unique solution (unless r is larger than any proper-divisor of a-r).
This question already has answers here:
What's the difference between `1L` and `1`?
(4 answers)
Closed 7 years ago.
I'm very confused with the data structure concepts in R (those are much more easy to understand in SAS).
Is there any difference between x <- 1:5 and x <- c(1,2,3,4,5)?
From the environment window, I know that one is int and the other is num.
x and y below are not quite identical because they have different storage modes, as you discovered by using str(x) and str(y). In my experience, this distinction is unimportant 99% of the time; R uses fairly loose typing, and integers will automatically be promoted to double (i.e. double-precision floating point) when necessary. Integers and floating point values below the maximum integer value (.Machine$integer.max) can be converted back and forth without loss of information. (Integers do take slightly less space to store, and can be slightly faster to compute with as #RichardScriven comments above.)
If you want to create an integer vector, append L as below ... or use as.integer() as suggested in comments above.
x <- 1:5
y <- c(1,2,3,4,5)
z <- c(1L,2L,3L,4L,5L)
all.equal(x,y) ## test for _practical_ equivalence: TRUE
identical(x,y) ## FALSE
identical(x,z) ## TRUE
storage.mode() and class() may also be useful, as well as is.integer(), is.double(), as.integer(), as.double(), is.numeric() ...
This question already has answers here:
Why are these numbers not equal?
(6 answers)
Closed 8 years ago.
Does the last statement in this series of statements make logical sense to anybody else? R seems to give similar results for a small subset of possible sums of decimals under 1. I cannot recall any basic mathematical principles that would make this true, but it seems to be unlikely to be an error.
> 0.4+0.6
[1] 1
> 0.4+0.6==1.0
[1] TRUE
> 0.3+0.6
[1] 0.9
> 0.3+0.6==0.9
[1] FALSE
Try typing 0.3+0.6-0.9, on my system the result is -1.110223e-16 this is because the computer doesn't actually sum them as decimal numbers, it stores binary approximations, and sums those. And none of those numbers can be exactly represented in binary, so there is a small amount of error present in the calculations, and apparently it's small enough not to matter in the first one, but not the second.
Floating point arithmetic is not exact, but the == operator is. Use all.equal to compare two floating point values in R.
isTRUE(all.equal(0.3+0.6, 0.9))
You can also define a tolerance when calling all.equals.
isTRUE(all.equal(0.3+0.6, 0.9, tolerance = 0.001))
This question already has answers here:
Why are these numbers not equal?
(6 answers)
Closed 8 years ago.
Why does this simple statement evaluate to FALSE in R?
mean(c(7.18, 7.13)) == 7.155
Furthermore, what do I have to do in order to make this a TRUE statement? Thanks!
Floating point arithmetic is not exact. The answer to this question has more information.
You can actually see this:
> print(mean(c(7.18,7.13)), digits=16)
[1] 7.154999999999999
> print(7.155, digits=16)
[1] 7.155
In general, do not compare floating point numbers for equality (this applies to pretty much every programming language, not just R).
You can use all.equal to do an inexact comparison:
> all.equal(mean(c(7.18,7.13)), 7.155)
[1] TRUE
It's probably due to small rounding error. Rounding to the third decimal place shows that they are equal:
round(mean(c(7.18, 7.13)), 3) == 7.155
Generally, don't rely on numerical comparisons to give expected logical outputs :)