Skip to content

Introductory Resources

3 messages · RBaskin@ahrq.gov, Spencer Graves, Duncan Murdoch

#
I've been using S-Plus almost daily for roughly 7 years and testing R 
daily for the past 4 months.  In my opinion, roughly 90% of the 
differences I've seen are in R's favor, e.g., the "log" options in the 
probability functions.

	  I think the future lies with R, because I guessing that much of the 
most advanced algorithm development must be in R:  I can modify an R 
function and give it to the world;  if others find my modification 
useful, I get recognized for having made a contribution to science and 
humanity.  If I do that with an S-Plus function, I'm a thief, because 
I've stolen Insightful's intellectual property.

	  In brief, I believe that R is already superior to S-Plus, and the 
difference is increasing.  I'm telling my collaborators who use S-Plus 
that our new software development should be tested in both R and S-Plus 
so we can switch whenever we need to.

Hope this helps.
Spencer Graves
p.s.  You'll find much more discussion of this by searching the r-news 
archives, "http://www.r-project.org/" -> Search -> "R Search Site".
RBaskin at ahrq.gov wrote:
#
On Fri, 6 Jun 2003 12:04:47 -0400 , you wrote in message
<3598558AD728D41183350008C7CF291C0F16B7F6 at exchange1.ahrq.gov>:
You need to download the source code to R from CRAN (e.g.
cran.mirrors.pair.com), it's not in the precompiled binaries.  You'll
find the tests in the "tests" subdirectory.  They consist of pairs of
foo.R and foo.Rout.save files.  When you run the tests via "make
check", foo.Rout will be produced, and you'll be warned about
differences from foo.Rout.save.

Testing also runs almost all of the examples in every help file, and
aborts if any generate errors (or warnings, I forget just now...).
Package writers can include their own test scripts and saved output
files.
option(na.action=<some function>) will control how all well-behaved
functions handle NAs, but not all functions are well-behaved.
Complain about those that should be but aren't (to the package
maintainer in case of a contributed package, here or to r-bugs in case
of a built-in package).
Yes, I think this is similar in R and S-PLUS, so you might run into
the same problems.  Generally it's easy using ellipses, but if the
argument name for your function happens to be the prefix of an
argument name for the Bootstrap function, then you'll get a match
there, instead of where you want it.  

For example, in R bootstrapping can be done using the function boot()
in library(boot).  It has arguments:

 boot(data, statistic, R, sim="ordinary", stype="i", 
          strata=rep(1,n), L=NULL, m=0, weights=NULL, 
          ran.gen=function(d, p) d, mle=NULL, ...)

The ellipses will pass other arguments to the function passed as the
statistic argument, but if you named them "str" they'd match "strata"
instead of being passed to "...".  Thus

 boot(vname, median, na.rm=T)

should work, but 

 myfunc <- function(x, str) median(x, na.rm=str)

 boot(vname, myfunc, str=T)

would not.
S-PLUS has a more polished GUI.  R is more responsive to bug reports.

Duncan Murdoch