Hi Emma,
unfortunately, rounding variables before taking the difference will not
solve your problem, because the *rounded* variables are subject to the
same (effectively) random internal representation. Examples:
> round(8.3,20)-round(7.3,20)>=1
[1] TRUE
> round(2.3,20)-round(1.3,20)>=1
[1] FALSE
> round(8.3,1)-round(7.3,1)>=1
[1] TRUE
> round(2.3,1)-round(1.3,1)>=1
[1] FALSE
I'm afraid you will need to think about what you really need your
comparison for and whether this problem really affects your results. For
example, if you are doing a large number of such comparisons, the effect
may only affect a few of them and basically average out (sometimes going
one way, sometimes the other), so the end results may be stable.
Good luck!
Stephan
emma jane schrieb:
Thanks Greg, that does make sense. And I've solved the problem by rounding
the variables before taking the difference between them.
Thanks to all who replied.
Emma JaneÂ
________________________________
From: Greg Snow <[EMAIL PROTECTED]>
.com.br>; Wacek Kusnierczyk <[EMAIL PROTECTED]>; Chuck Cleland <[EMAIL
PROTECTED]>
Cc: R help <[EMAIL PROTECTED]>
Sent: Tuesday, 9 December, 2008 16:30:08
Subject: RE: [R] Logical inconsistency
Some (possibly all) of those numbers cannot be represented exactly, so there is
a chance of round off error whenever you do some arithmetic, sometimes the
errors cancel out, sometimes they don't. Consider:
print(8.3-7.3, digits=20)
[1] 1.000000000000001
print(11.3-10.3, digits=20)
[1] 1
So in the first case the rounding error gives a value that is slightly greater
than 1, so the greater than test returns true (if you round the result before
comparing to 1, then it will return false). In the second case the
uncertainties cancelled out so that you get exactly 1 which is not greater than
1 an so the comparison returns false.
Hope this helps,
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
801.408.8111
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
project.org] On Behalf Of emma jane
Sent: Tuesday, December 09, 2008 7:02 AM
To: Bernardo Rangel Tura; Wacek Kusnierczyk; Chuck Cleland
Cc: R help
Subject: Re: [R] Logical inconsistency
Many thanks for your help, perhaps I should have set my query in
context .... !
I'm simply calculating an indicator variable [0,1] based on the whether
the difference between two measured variables is > 1 or <=1.
I understand the FAQ about floating point arithmetic, but am still
puzzled that it only apparently applies to certain elements, as
follows:
8.8 - 7.8 > 1
TRUE
8.3 - 7.3 > 1
TRUE
However,
10.2 - 9.2 > 1
FALSE
11.3 - 10.3>1
 FALSE
Emma Jane
________________________________
From: Bernardo Rangel Tura <[EMAIL PROTECTED]>
To: Wacek Kusnierczyk <[EMAIL PROTECTED]>
Cc: R help <[EMAIL PROTECTED]>
Sent: Saturday, 6 December, 2008 10:00:48
Subject: Re: [R] Logical inconsistency
On Fri, 2008-12-05 at 14:18 +0100, Wacek Kusnierczyk wrote:
Berwin A Turlach wrote:
Dear Emma,
On Fri, 5 Dec 2008 04:23:53 -0800 (PST)
Please could someone kindly explain the following inconsistencies
I've discovered__when performing logical calculations in R:
8.8 - 7.8 > 1
TRUE
8.3 - 7.3 > 1
TRUE
Gladly:Â FAQ 7.31
http://cran.at.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-
th
ink-these-numbers-are-equal_003f
well, this answer the question only partially. this explains why a
system with finite precision arithmetic, such as r, will fail to be
logically correct in certain cases. it does not explain why r, a
language said to isolate a user from the underlying implementational
choices, would have to fail this way.
there is, in principle, no problem in having a high-level language
perform the computation in a logically consistent way. for example,
bc is an "arbitrary precision calculator language", and has no
problem
with examples as the above:
bc <<< "8.8 - 7.8 > 1"
# 0, meaning 'no'
bc <<< "8.3 - 7.3 > 1"
# 0, meaning 'no'
bc <<< "8.8 - 7.8 == 1"
# 1, meaning 'yes'
the fact that r (and many others, including matlab and sage, perhaps
not
mathematica) does not perform logically here is a consequence of its
implementation of floating point arithmetic.
the faq you were pointed to, and its referring to the goldberg's
article, show that r does not successfully isolate a user from
details
of the lower-level implementation.
vQ
Well, first of all for 8.-7.3 is not equal to 1 [for computers]
8.3-7.3-1
[1] 8.881784e-16
But if you use only one digit precision
round(8.3-7.3,1)-1
[1] 0
round(8.3-7.3,1)-1>0
[1] FALSE
round(8.3-7.3,1)==1
[1] TRUE
So the problem is the code write and no the software
--
Bernardo Rangel Tura, M.D,MPH,Ph.D
National Institute of Cardiology
Brazil
    [[alternative HTML version deleted]]
[[alternative HTML version deleted]]
------------------------------------------------------------------------
______________________________________________
R-help@r-project.org mailing list
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@r-project.org mailing list
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.
