On Tue, Aug 23, 2011 at 8:17 PM, Daniel Lai <dan...@bccrc.ca> wrote: > Greetings all, > > I'm porting an algorithm from MATLAB to R, and noticed some minor > discrepancies in small decimal values using rowSums and colSums which are > exacerbated after heavy iteration and log space transformation. This was > rather perplexing as both programs claimed and appeared to use the IEEE 754 > standard for floating point arithmetic (confirmed with manual basic > operations). After some tracing and testing, I've managed to isolated a > minimal working example as follows: > > a = 0.812672 > b = 0.916541 > c = 0.797810 > sum(c(a, b, c)) == (a + b + c) > [1] FALSE
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.
