Hi all,
>From what I can see from my checkout of the Rsources (in src/main/summary.c
as pointed out by others) sums are calculated the "naive" way (see rsum c
function) but means are actually calculated something akin to the Neumaier
way (see real_mean c function).
Just an fyi.
~G
On Thu, Feb
Specifically: https://svn.r-project.org/R/trunk/src/main/summary.c
And if you don't want to deal with Subversion, you can look at the
read-only github mirror:
https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/main/summary.c#L115-L131
On Thu, Feb 21, 2019 at 11:57
On 2/20/19 2:55 PM, Rampal Etienne wrote:
Dear Tomas,
Where do I find these files? Do they contain the code for the sum function?
Yes.
https://svn.r-project.org/R/trunk/
David
What do you mean exactly with your point on long doubles? Where can I find
documentation on this?
Cheers, Ram
Dear Will,
This is exactly what I find.
My point is thus that the sum function in R is not a naive sum nor a
Kahansum (in all cases), but what algorithm is it using then?
Cheers, Rampal
On Tue, Feb 19, 2019, 19:08 William Dunlap The algorithm does make a differece. You can use Kahan's summati
Dear Paul,
Thank you for thinking with me. I will respond to your options:
>
> 0/ Your code is wrong, but that seems unlikely on such a simple
> calculations.
>
It's really just a comparison of the sum function in Fortran with that of
R. If instead I use the naive summation with a for loop in bo
Dear Tomas,
Where do I find these files? Do they contain the code for the sum function?
What do you mean exactly with your point on long doubles? Where can I find
documentation on this?
Cheers, Rampal
On Mon, Feb 18, 2019, 15:38 Tomas Kalibera See do_summary() in summary.c, rsum() for doubles.
Dear Rampal,
you can download R source code in form of a tarball or from subversion,
please see
https://cran.r-project.org/doc/manuals/R-admin.html#Obtaining-R
https://cran.r-project.org/doc/manuals/R-admin.html#Using-Subversion-and-rsync
There is also a web access to subversion, so specifically
Someone said it used a possibly platform-dependent
higher-than-double-precision type.
By the way, in my example involving rep(1/3, n) I neglected to include the
most precise
way to calculate the sum: n%/%3 + (n%%3)/3.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Wed, Feb 20, 2019 at 2:45 PM
>
> On 2019-02-19 2:08 p.m., William Dunlap via R-devel wrote:
>> The algorithm does make a differece. You can use Kahan's summation
>> algorithm (https://en.wikipedia.org/wiki/Kahan_summation_algorithm) to
>> reduce the error compared to the naive summation algorithm. E.g., in R
>> code:
>>
>>
This SO question may be of interest:
https://stackoverflow.com/questions/38589705/difference-between-rs-sum-and-armadillos-accu/
which points out that sum() isn't doing anything fancy *except* using
extended-precision registers when available. (Using Kahan's algorithm
does come at a computat
The algorithm does make a differece. You can use Kahan's summation
algorithm (https://en.wikipedia.org/wiki/Kahan_summation_algorithm) to
reduce the error compared to the naive summation algorithm. E.g., in R
code:
naiveSum <-
function(x) {
s <- 0.0
for(xi in x) s <- s + xi
s
}
kahanSum
(I didn't see anyone else answer this, so ...)
You can probably find the R code in src/main/ but I'm not sure. You are
talking about a very simple calculation, so it seems unlike that the
algorithm is the cause of the difference. I have done much more
complicated things and usually get machine
See do_summary() in summary.c, rsum() for doubles. R uses long double
type as accumulator on systems where available.
Best,
Tomas
On 2/14/19 2:08 PM, Rampal Etienne wrote:
Hello,
I am trying to write FORTRAN code to do the same as some R code I
have. I get (small) differences when using the
13 matches
Mail list logo
