Sicco Schets reports problems transferring functions between two versions of
S-PLUS, which turn out to be from S-PLUS 6 to S-PLUS 2000. Although this is
somewhat to be expected due to the very different versions, the problems he
reports are really just "features" of the language. Details below.
> The PC trial version I was testing on is Splus-2000 Release 3 for
> Windows.
In that case, you were tranferring code unaltered from S-PLUS 6 for Unix to
S-PLUS 2000 Windows, a version of S-PLUS more than 18 months older and based
on an entirely different language engine. S-PLUS is largely
backwards-compatibility, but (lacking the gift of prescience) we do not
claim such levels of forwards-compatibility. Had you moved code between
S-PLUS 6 for Unix and S-PLUS 6 for Windows I'd have expected no such
problems. We provide tools for moving code between S-PLUS 2000 for Windows
and S-PLUS 6 for Windows, and also between S-PLUS 3.4 for Unix and S-PLUS
5/6 for Unix, but not in the reverse direction.
> if (reg expr)
> {
> code
> }
> else
> {
> code
> }
>
> doesn't work
I agree this could be considered a bug, but this kind of thing happens with
all interpreted languages. Scripts are processed line-by-line, and if a
line forms the end of a complete expression, the expression is evaluated.
else clauses aren't the only instance of this:
x <- 10
-y
Should this be interpreted as "x <- 10-y", or as two separate expressions?
The rule of stopping at complete expressions is sometimes inconvenient, but
not having it can introduce much worse ambiguities. (You might think that
when reading from script files, looking ahead to the next line could resolve
ambiguities, as in the if/else case. But then, pasting text to the command
line as opposed to using source() could have different results. That's bad
too.)
In any case, this issue exists in both S-PLUS 2000 and S-PLUS 6, so at least
it's backwards (and forwards!) compatible.
> Or the mode of e.g a data.frame is returned by a function
> differently on the 2 platforms.
I don't believe this is true. There are several classes where the *class*
of an object will be different in S-PLUS 6 than S-PLUS 2000 (basic objects
like vectors and matrices come to mind), but the behaviour of mode() hasn't
changed.
> 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.
I don't believe this to be true either (although it's hard to tell exactly
what you mean).
> 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.
This behaviour exists in all versions of S-PLUS (since version 3, at least).
Like many aspects of the S language, the behaviour of factors is undoubtedly
quirky, but it is consistent. In S-PLUS 6 you can turn off automatic factor
coercieon with the options(stringsAsFactors=F). If your column really was
doubles, there must have been a text character there sometime for it to have
been converted to a factor.
As a final point, can I mention that the Technical Support team would easily
have been able to resolve all of these problems for you. Technical Support
is included with your first year after purchasing S-PLUS (and thereafter if
the support contract is maintained), and they are uniformly very helpful in
matters such as this.
In mounting exasperation,
# David Smith
> -----Original Message-----
> From: s-news-owner@lists.biostat.wustl.edu
> [mailto:s-news-owner@lists.biostat.wustl.edu]On Behalf Of Sicco Schets
> Sent: Thursday, September 20, 2001 01:34
> 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
>
|