As far as I am concerned, unless the documentation issues in Splus are
improved and the backward compatibility and cross platform compatibility are
addressed (at least via documentation) I can not consider Splus as a serious
programming language.
-----Original Message-----
From: Sicco Schets [SMTP:Sicco.Schets@asml.com]
Sent: Thursday, September 20, 2001 4:34 AM
To: Prof Brian Ripley
Cc: 's-news@wubios.wustl.edu'
Subject: Re: [S] Differences between UNIX and PC version of
Splus
Thanks for replies,
The PC trial version I was testing on is Splus-2000 Release 3 for
Windows. I
must confess that my S programming doesn't include any fancy OO
programming
or the like, nor any external calls.
I do not create my own methods or classes either. So nothing fancy.
An example of the warnings/errors I got (I consider a warning just
as bad as
an error since it takes just as much effort to solve) is for
instance the
'if-else' construction. Sometimes in UNIX version, if you write,
if (reg expr)
{
code
}
else
{
code
}
doesn't work and you need to write,
if (reg expr)
{
code
} else
{
code
}
but this is not always (???).
Or the mode of e.g a data.frame is returned by a function
differently on the
2 platforms. And if I have a statement like 'return(list(a=bla,
b=blabla)'
inside a 'tapply' then on the PC version I can reference the vars
with $a and
$b. However, on the UNIX version I can't.
Another issue is that you can have a data.frame (made with
read.table()) with
a column of doubles. If you ask for the mode of this column it will
tell you
it's numeric, but if you then multiply this column with any number
you get an
error stating that multiplication cannot be done on factors. Who the
heck
told 'em to be a factor? The same happens if you then try to make
this column
as.numeric. The strangest thing is that the read.table command
doesn't turn
every numeric column into a 'hidden' factor, but just sometimes.
Why????
Another typical example is that you can have a data.frame fo mode
'list',
which is kind of useless since you can't do much with a list (like
calculate
var()) giving errors like "cannot coerce from mode list to double".
After
doing some vague manipulations of the data.frame (like using lapply
and
subtracting some vector), the data.frame somehow looses its 'list'
mode,
whilst when printing both versions of the same data.frame they look
exactly
the same. In principle I do not like lists (and especially lists
within a
list) as it is so difficult to get your data out in a usable form.
These are just some of the examples I can come up with now, but most
times
the issues or of the same sort.
I feel that I lack the exact understanding of how Splus deal with
mode's and
what the exact ins and outs are of each mode and then also how to
deal with
them. I cannot find good documentation on this subject nor do any
courses
I've seen or had really address this. Does anyone have a good
advice?
regards
Sicco
Prof Brian Ripley wrote:
> On Tue, 18 Sep 2001, Sicco Schets wrote:
>
> > Hi,
> >
> > I thought today to try a test of my Splus code, programmed under
Splus6
> > for UNIX, and try it on the PC version (a trial version) to test
> > portability and speed.
>
> (Just checking: `the PC version' means under Windows, not Linux,
and this
> is a trial of release 1, not a release candidate? The actual
release is a
> lot stabler.)
>
> > Conclusions:
> > 1) Not portable at all!!! A lot of warnings and errors in most
basic
> > things, especially with coercion.
> > 2) PC seems about 2-3 times faster (400MHz PC with 128MB versus
and SUN
> > Ultra 60 with 512 MB).
> >
> > Is there any easy way to port S code between PC and UNIX
versions?
>
> I am not seeing this difficulty, although perhaps as a beta tester
I got
> used to some differences. In my experience:
>
> 1) The PC version is pickier than the Unix version, especially
about
> classes and method definitions.
>
> 2) It's quite a bit faster (Windows 2000 vs Linux on the same
hardware).
>
> According to David Smith, when 6.1 for Unix/Linux appears both
differences
> will go away. It might be helpful to think of the Windows version
> as 6.1-epsilon (not 6.0.2 or soon .3).
>
> Over the last week I have ported half a dozen libraries to S-PLUS
6 for
> Windows with minimal difficulties. Almost all those I have
encountered
> stem from compiling C code, in particular the use of __stdcall in
VC++ and
> incomplete or incorrect headers (not just in the code I am
compiling,
> either, but also in VC++). I've resorted to the mingw port of gcc
several
> times to get over this: no problem as it's a good compiler and
> well-supported by the S-PLUS headers.
>
> The other tedious thing was migrating help files, but I find the
Perl
> script I wrote (available through the `S Programming' on-line
material)
> does the trick.
>
> We are moving our teaching next year (i.e. from October 1) to 6.0
on
> Windows and not seeing any problems in migrating material beyond
those
> mentioned above.
>
> --
> 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
>
>
---------------------------------------------------------------------
> 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 << File:
ATT136201.txt >> << File: ATT136202.txt >>
|