Hear, hear ! S-plus could have been a Microsoft product. It's
bloated and slow and it's everywhere.

Of course C does not stand for "computer".
The naming chain is CPL => BCPL => B => C. See Steve
Summit, C Programming FAQ's, number 20.38.

At 12:59 AM +0000 2/23/00, Radford Neal wrote:
>In article <[EMAIL PROTECTED]>,
>Frank E Harrell Jr  <[EMAIL PROTECTED]> wrote:
>
>  > S-Plus is a powerful object-oriented language based on the S
>  > language (created at the same place that created the C language -
>  > ATT Bell Labs - C is for "computer" S for "statistics").
>
>Usually, I find this sort of cheerleading just a bit annoying, but
>when given in response to a student's request for information about
>what to learn, it gets downright misleading.
>
>The truth:  S-Plus is not particularly powerful, and it's not
>particularly well designed.  Its implementation by the people at AT&T
>Bell labs is downright incompetent.  Of course, it has lots of support
>for statistical methods, making it useful for statisticians to know,
>but it's a shame that this has had the effect of locking academic
>statisticians into this indifferently-designed and badly-implemented
>language, which is completely unusable some purposes, such as Markov
>chain Monte Carlo computations.  The free "R" look-alike for S may fix
>at least the badly-implemented part of this dilema.
>
>Below is a posting I recently made to sci.stat.math, remarking on the
>amazingly *worse* performance of the latest release of S-Plus - which
>is up to SEVENTEEN times slower than the previous release.
>
>Finally, I doubt very much that the "C" language stands for "computer".
>What would it's predecessor language, called "B", have stood for?
>
>    Radford Neal
>
>-------------------------------------------------------------------------
>
>In article <[EMAIL PROTECTED]>,
>Thomas Gatliffe  <[EMAIL PROTECTED]> wrote:
>
>  >R is a substitute but if you are really looking for the power of S-Plus you
>  >won't be satisfied.
>
>This depends on what you mean by "power".  S-Plus has some facilities
>that aren't in R, and some of the ones that R does have seem to be a
>bit less mature - eg, I couldn't off hand figure out how to get R's lm
>function to accept a "tolerance" parameter to allow it to accept
>almost singular (but still doable) problems.  One the other hand, if
>by "power" you mean the ability to do anything involving substantial
>computation that isn't done by one of the built-in funcitons written
>in C, then S-Plus is about the worst language you could possibly choose,
>whereas R looks like it would be viable (though not especially fast).
>
>What is most incredible is that the inefficiency of S-Plus has gotten
>substantially worse in the latest release.  It's so bad that I wonder
>if there is something peculiar about the version for our machine (SGI).
>Here are the times (in seconds) to run five simple test programs that
>are listed below:
>
>     Program:    test1    test2     test3    test4    test5
>  Iterations:      500     1000     10000     1000   100000
>
>  S-PLUS 3.4:     18.3      9.0      38.4     31.0    232.9
>  S-PLUS 5.1:     75.0    152.6     317.1    544.8    224.1
>    R 0.90.1:     56.5      5.7      47.0     18.1     27.9
>
>All results are on an SGI system with a 194 MHz R10000 processor.
>
>Looking first at the OLD version of S-Plus (3.4) versus R, one sees
>that on the first test, involving the built-in lm function, R is about
>three times slower, perhaps due to the quality of the implementation
>of that particular function.  On the other tests, R is about the same
>speed as the old S-Plus, EXCEPT for test5, where the old S-Plus is
>about 10 times slower.  This test appears to activate the S-Plus
>design flaw that causes some memory not to be recovered in loops.
>Execution then gets slower and slower as the loop goes round (it takes
>the old S-Plus only 5.3 seconds to do 10000 iterations, which would
>lead you to think it would take 53 seconds, not 232, to do 100000).
>Perusal of this test (below) will show you that it's not doing
>anything that you might not want to do in lots of your programs.
>Trying to avoid anything that might activate this bug while writing
>programs is a ridiculous waste of your time.
>
>Turning now to the NEW S-Plus (5.1), one sees that the test involving
>the built-in lm function is now about four times slower.  Not too
>impressive an "upgrade".  But that's nothing compared to tests 2 to 4,
>however - they're up to 17 times slower!  And the last test shows that
>they still haven't fixed the memory bug.
>
>This new release is so ridiculously bad that I wonder whether there's
>something wrong with just the version for SGI machines.  I'd be
>interested to find out what the results are on other machines.  Anyone
>else with both the old and the new S-Plus want to try?
>
>For comparison, the Maple equivalent of test5 (see below) takes 3.5
>seconds to run on the same SGI machine as was used for the above
>tests.  Clearly, R is not a particularly efficient interpreter either.
>R does seem to avoid any truly spectacular inefficiencies, however.
>
>Here are the programs, which don't do anything interesting or sensible
>- I just typed in various things somewhat arbitrarily - but do do the
>sort of things that one will want to do now and then.  They were run
>for the numbers of iterations (n) shown above.  Times were from the
>Unix "time" command, applied to an interactive run in which the
>function was read with "source", then run, after which q() was
>immediately done.  For R, the workspace was saved at the end to match
>the behaviour of S in saving variables automatically.
>
>test1:
>
>time.test1 <- function (n)
>{
>   x1 <- c(1,4,1,3,2,3,4)
>   x2 <- c(5,0,2,3,5,2,1)
>    y <- c(4,3,2,4,3,2,1)
>
>   for (i in 1:n)
>   { ys <- sample(y)
>     m <- lm(ys~x1+x2)
>   }
>
>   invisible()
>}
>
>test2:
>
>time.test2 <- function (n)
>{
>   x1 <- c(1,4,1,3,2,3,4)
>   x2 <- c(5,0,2,3,5,2,1)
>    y <- c(4,3,2,4,3,2,1)
>
>   k <- 0
>
>   for (i in 1:n)
>   { ys <- sample(y)
>     if (cor(ys,x1)>cor(ys,x2))
>     { k <- k+1
>     }
>   }
>
>   invisible()
>}
>
>test3:
>
>time.test3 <- function (n)
>{
>   x1 <- c(1,4,1,3,2,3,4)
>   x2 <- c(5,0,2,3,5,2,1)
>    y <- c(4,3,2,4,3,2,1)
>
>   k <- 0
>
>   for (i in 1:n)
>   { for (j in 1:length(y))
>     { y[j] <- x1[j] + x2[j]*y[j]
>       if (y[j]<10 || y[j]>10)
>       { y[j] <- 2.3
>       }
>     }
>   }
>
>   invisible()
>}
>
>test4:
>
>time.test4 <- function (n)
>{
>   x1 <- c(1,4,1,3,2,3,4)
>   x2 <- c(5,0,2,3,5,2,1)
>    y <- c(0,0,0,0,0,0,0)
>
>   k <- 0
>
>   for (i in 1:n)
>   { for (j in 1:length(y))
>     { y[j] <- cor(x1+x2,x1-x2*j)
>     }
>     for (j in 1:length(x1))
>     { x1[j] <- 0.1 - x1[j]
>     }
>   }
>
>   invisible()
>}
>
>test5:
>
>time.test5 <- function (n)
>{
>   k <- 0
>   for (j in 1:n)
>   { v <- c(1,2,j,j,3)
>     if (v[2]==2)
>     { k <- k+1
>     }
>   }
>
>   invisible()
>}
>
>Here's the Maple equivalent of test5:
>
>test := proc(n)
>    local j,k,v;
>    k := 0;
>    for j to n do
>      v := [1,2,j,j,3];
>      if v[2] = 2 then
>        k := k+1
>      fi
>    od;
>end;
>
>
>----------------------------------------------------------------------------
>Radford M. Neal                                       [EMAIL PROTECTED]
>Dept. of Statistics and Dept. of Computer Science [EMAIL PROTECTED]
>University of Toronto                     http://www.cs.utoronto.ca/~radford
>----------------------------------------------------------------------------
>
>
>===========================================================================
>   This list is open to everyone. Occasionally, people lacking respect
>   for other members of the list send messages that are inappropriate
>   or unrelated to the list's discussion topics. Please just delete the
>   offensive email.
>
>   For information concerning the list, please see the following web page:
>   http://jse.stat.ncsu.edu/
>===========================================================================

===
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
US mail: 8142 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550;  fax (310)-206-5658;  email: [EMAIL PROTECTED]
    http://www.stat.ucla.edu/~deleeuw and http://home1.gte.net/datamine/
============================================================================
          No matter where you go, there you are. --- Buckaroo Banzai
============================================================================


===========================================================================
  This list is open to everyone. Occasionally, people lacking respect
  for other members of the list send messages that are inappropriate
  or unrelated to the list's discussion topics. Please just delete the
  offensive email.

  For information concerning the list, please see the following web page:
  http://jse.stat.ncsu.edu/
===========================================================================

Reply via email to