Hi Barry,
Shock and horror indeed, addition is not _associative_, at least for
floating point arithmetic [1].
Flipping the order of the operands seems to be the explanation of the
discrepancies between R and MATLAB as you suggest:
In R:
a = 0.812672
b = 0.916541
c = 0.797810
sprintf('%.30f', a+b+c)
[1] "2.527023000000000241271891354700"
sprintf('%.30f', c+a+b)
[1] "2.527022999999999797182681504637"
sprintf('%.30f', sum(c(a,b,c)))
[1] "2.527022999999999797182681504637"
In MATLAB:
a = 0.812672;
b = 0.916541;
c = 0.797810;
sprintf('%.30f', a+b+c)
ans = 2.527023000000000241271891354700
sprintf('%.30f', c+a+b)
ans = 2.527022999999999797182681504637
sprintf('%.30f', sum([a,b,c]))
ans = 2.527023000000000241271891354700
From this, I'll have to conclude that R's sum() is correct, but
probably internally flipping operands.
Many thanks,
Daniel
[1] http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
On 23/08/11 3:20 PM, Barry Rowlingson wrote:
Its probably to do with the order of summations. With your a,b,c you get:
> (a+b+c) == (c+b+a)
[1] TRUE
> (a+b+c) == (c+a+b)
[1] FALSE
shock horror, addition is not associative[1]. Lets investigate:
> sum(c(a,b,c)) == c+a+b
[1] TRUE
> sum(c(a,b,c)) == a+c+b
[1] TRUE
'sum' seems to get the same answer as adding the first and the third,
then adding the second - explicitly:
> sum(c(a,b,c)) == (a+c)+b
[1] TRUE
I'm not sure what it would do for four values in the sum. Have fun
finding out. Does matlab similarly have a+b+c != c+b+a?
Barry
[1] or commutative or distributive or one of those -ives you learn one
day in school. Too lazy to wikipedia it right now...
______________________________________________
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.
