Thanks to everyone that rapidly clarified the issue of integer vs
double in S-plus, and also the different handling in R!
Cheers,
Henrik
I include some representative comments:
Greg:
According to the help file on "double", we shouldn't have to worry:
"In most S-PLUS expressions it is not necessary to explicitly ensure
that data are of a particular storage mode. When testing for data
suitable for arithmetic, for example, it is better to use is.numeric(x),
which will return TRUE for any numeric object. Normally, S-PLUS does
numeric computations with double precision. Explicit reference to
storage mode double is usually only relevant when passing arguments to
Fortran or C routines that have arguments with double precision or float
declarations..."
Dan Rie:
It looks like S-Plus is attempting to use the two numbers as integers in
the case that produces the NA. Although S-Plus 6.1 and 6.2 fail at this
calculation, Neither S-Plus 2000 nor R had any problem with the example.
Chuck Taylor @ Insightful:
S-PLUS parses 46341 as an integer, so 46341*46341 produces integer overflow
on a 32-bit computer. The largest integer that can be represented in S-PLUS
on your computer is given by .Machine$integer.max:
.Machine$integer.max
[1] 2147483647
I believe that what you want is floating point arithmetic, so try
46341.*46341. instead. Using the decimal points explicitly forces S-PLUS to
use floating point arithmetic.
46341.*46341.
[1] 2147488281
Chuck Taylor
Sr. Quality Assurance Engineer
Insightful Corporation
Seattle, WA, USA
Sundar and Brian:
Sundar Dorai-Raj wrote:
Brian S Cade wrote:
Okay, so if this an issue of integer vs double precision real
storage, why is this same calculation not a problem in R. What is
done differently between S-Plus and R? Curious to avoid future
problems.
Brian
Because of this:
S-PLUS 6.2:
> storage.mode(46432)
[1] "integer"
> storage.mode(46342*46342)
[1] "integer"
R 2.2.1:
> storage.mode(46432)
[1] "double"
> storage.mode(46342*46342)
[1] "double"
I'm using WinXP. Does this help?
--sundar
Brian S. Cade
U. S. Geological Survey
Fort Collins Science Center
2150 Centre Ave., Bldg. C
Fort Collins, CO 80526-8818
email: brian_cade@usgs.gov
tel: 970 226-9326
*Sundar Dorai-Raj <sundar.dorai-raj@pdf.com>*
Sent by: s-news-owner@lists.biostat.wustl.edu
03/03/2006 01:03 PM
To
henrik.parn@bio.ntnu.no
cc
s-news@lists.biostat.wustl.edu
Subject
Re: [S] multiplication problem - what happens at 46341?
Hi, Henrik,
You've overlooked how big an integer S-PLUS can store as an integer.
That's why:
46342.*46342
will work, but
46342*46342
won't. This is becuase the first forces the storage to double.
As for your function, length(x) returns a integer. So, try:
skew.sokal <- function(x) {
n <- as.numeric(length(x))
m3 <- n * sum((x - mean(x))^3)/((n - 1) * (n - 2))
s3 <- sqrt(var(x))^3
m3/s3
}
set.seed(42)
x <- rnorm(46343)
skew.sokal(x)
--------------------------------------------------------------------
This message was distributed by s-news@lists.biostat.wustl.edu. To
unsubscribe send e-mail to s-news-request@lists.biostat.wustl.edu with
the BODY of the message: unsubscribe s-news
--
************************
Henrik Pärn
Department of Biology
NTNU
7491 Trondheim
Norway
+47 735 96282 (office)
+47 909 89 255 (mobile)
+47 735 96100 (fax)
************************
|