From wsi@gcal.ac.uk  Thu Sep 13 15:19:32 2001
From: wsi@gcal.ac.uk (Bill Simpson)
Date: Thu, 13 Sep 2001 15:19:32 +0100 (BST)
Subject: [Rd] sum overflow (PR#1091)
In-Reply-To: <Pine.LNX.4.31.0109131443170.14713-100000@gannet.stats>
Message-ID: <Pine.LNX.4.10.10109131504160.5394-100000@localhost.localdomain>

> 
> 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.
Well you saw where I was hit by unexpected integers. BTW did you notice
that integers in a<-1:1000 caused a problem in
sum(a*a) * sum(b*b)
and not in 
crossprod(a,a) * crossprod(b,b)?
sum() preserved the integers as integers and crossprod() coerced them to
doubles.

I don't think you can do any arithmetic at all unless you make some
assumptions. Are you saying I should do as.double(a) every time I do
anything with vectors in R???

As it now stands, R makes most things double, with some exceptions as you
give below. Why not eliminate the exceptions?

> 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.
Yes, that's fine.

Bill

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] sum overflow (PR#1091)
Bill Simpson