>>>>> "GaGr" == Gabor Grothendieck <ggrothendi...@gmail.com> >>>>> on Tue, 17 Feb 2009 20:53:18 -0500 writes:
GaGr> Check out sum.exact and cumsum.exact in the caTools package. >> library(caTools) GaGr> Loading required package: bitops >> x <- 1/(12:14) >> sum(x) - cumsum(x)[3] GaGr> [1] 2.775558e-17 >> sum.exact(x) - cumsum.exact(x)[3] GaGr> [1] 0 [ buuh, humbug! ] The 'NEWS' for R-devel (to become R 2.9.0 in April) has the following entry o cumsum(x) and cumprod(x) for double precision x now use a long double accumulator where available and so more closely match sum() and prod() in potentially being more accurate. and indeed, in R-devel, sum(x) - cumsum(x)[length(x)] gives 0 for your example. Martin Maechler, ETH Zurich and R-core team GaGr> On Tue, Feb 17, 2009 at 5:12 PM, Stavros Macrakis <macra...@alum.mit.edu> wrote: >> I recently traced a bug of mine to the fact that cumsum(s)[length(s)] >> is not always exactly equal to sum(s). >> >> For example, >> >> x<-1/(12:14) >> sum(x) - cumsum(x)[3] => 2.8e-17 >> >> Floating-point addition is of course not exact, and in particular is >> not associative, so there are various possible reasons for this. >> Perhaps sum uses clever summing tricks to get more accurate results? >> In some quick experiments, it does seem to get more accurate results >> than cumsum. >> >> It might be worth documenting. >> >> -s ______________________________________________ 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.