[Rd] sum overflow (PR#1091)

[Prof Brian Ripley]

On Thu, 13 Sep 2001, Bill Simpson wrote:

> > It's not a problem with sum:
> >
> > > sum(a*a)
> > [1] 333833500
> > > sum(b*b)
> > [1] 333833500
> >
> > are accurate.
> >
> > The overflow is in the integer arithmetic for *.  That's a question for
> > your C run-time system.  On a 64-bit machine you might get different
> > results (although most use 32-bit ints, including mine).
> >
> > If you use integers you need to be aware of the consequences.  It's a
> > feature not a bug.
> I thought R used an internal rep that was double in all cases.

Assumed, I guess, as I've never seen that in the manuals.

> Now I'm confused:
> > a<-(1:1000)
> > b<-(1:1000)
> > sum(a*a)*sum(b*b)
> [1] -652010736
> > a<-(1:1000)/1.0
> > b<-(1:1000)/1.0
> > sum(a*a)*sum(b*b)
> [1] 1.114448e+17
>
> So  R somehow decides whether to use an integer or a double
> representation? Please tell me the rule used by R so I will know in the
> future.

It uses what you tell it to in general.  Integers will be handled as
integers, but as in C integer/numeric gives a numeric.  Rather than
learn rules, use typeof or storage.mode as in
> typeof(1:1000)
[1] "integer"

to find out, or make explicit coercions (as.numeric) if you want to make
assumptions about objects.

At present you are only likely to get integers from m:n and similar
seq() calls, and from unclass on a factor.  But no one is saying that will
not change in the future (and it did from S3 to S4).  And you could
always have a user who used as.integer explicitly.

Brian

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._