-----Original Message-----
From: Liaw, Andy [mailto:andy_liaw at merck.com]
Sent: Thursday, September 27, 2001 4:28 PM
To: 'Sinclair, Andrew (MIP London)'; 's-news'
Subject: Re: [S] A plea (was RE: [S] Differences between UNIX and PC
Couldn't agree more. I recently heard that Eric Raymond (an
Open Source
advocate) is putting together a web site (?) that tells
people how to ask
questions on the 'Net so as to maximize their chance of getting useful
answers. Seems like it would be a good place for some to
visit... unless
they are *not* interested in getting answers, but just wanted
to get it off
their chest...
Just my $0.02.
Andy
-----Original Message-----
From: Sinclair, Andrew (MIP London)
[mailto:ASinclair at maninvestmentproducts.com]
Sent: Thursday, September 27, 2001 11:18 AM
To: 's-news'
Subject: [S] A plea (was RE: [S] Differences between UNIX and
PC version
of Splus)
I just want to make a brief plea for people posting queries
to s-news to
include code fragments that can actually be run and demonstrate the
problem or error that they are referring to. This makes it
much easier
for respondents to give useful answers and saves a lot of
concerned.
For example it seems to me that most of the disagreements
in the diatribe below could more easily have been cleared up if
there were specific code fragments to discuss. I am sure
neither David Smith nor Sicco Schets is a liar. Either Sicco
has a bug in his code or he has uncovered a bug/inconsistency in
some version of Splus or he has misunderstood the results he is
getting. My point is that noone can tell because we can only
speculate about the exact situation in which he observed the
behaviour he mentions.
I do not intend to imply any criticism to either party in
this discussion.
Just a (hopefully) constructive comment about the usage of s-news.
Kind regards,
Andrew
-----Original Message-----
From: Sicco Schets [mailto:Sicco.Schets at asml.com]
Sent: Thursday, September 27, 2001 10:32 AM
To: David Smith
Cc: s-news at wubios.wustl.edu
Subject: Re: [S] Differences between UNIX and PC version of Splus
Hi,
Firstly, I want to mention that my first mail was not so much
intended for
people to solve the problem examples that I have. It was more
just to get
things of my chest about Splus. Of couse, I also hoped that
someone could point
me in the direction where I can learn more about modes,
coercion and the like,
because I still like to believe that the
errors/bugs/issues/features that I
observe are due to my own lack of this undersanding.
Furthermore, see my comments between the lines below.
David Smith wrote:
Sicco Schets reports problems transferring functions between
S-PLUS, which turn out to be from S-PLUS 6 to S-PLUS 2000.
somewhat to be expected due to the very different versions,
reports are really just "features" of the language.
The PC trial version I was testing on is Splus-2000
In that case, you were tranferring code unaltered from
S-PLUS 2000 Windows, a version of S-PLUS more than 18 months
on an entirely different language engine.
Actually I was porint code that worked on the PC version to
the UNIX version 6.
But I feel that the 'older' Windows version deals better with
these problems.
S-PLUS is largely
backwards-compatibility, but (lacking the gift of
claim such levels of forwards-compatibility. Had you moved
S-PLUS 6 for Unix and S-PLUS 6 for Windows I'd have
problems. We provide tools for moving code between S-PLUS
and S-PLUS 6 for Windows, and also between S-PLUS 3.4 for
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
all interpreted languages.
I agree, but why is this behavior not consistent? It is not
always that the
above code doesn't work!! PC version has no problems with it.
Scripts are processed line-by-line, and if a
line forms the end of a complete expression, the expression
else clauses aren't the only instance of this:
x <- 10
-y
Should this be interpreted as "x <- 10-y", or as two
The rule of stopping at complete expressions is sometimes
not having it can introduce much worse ambiguities. (You
when reading from script files, looking ahead to the next
ambiguities, as in the if/else case. But then, pasting text
line as opposed to using source() could have different
too.)
In any case, this issue exists in both S-PLUS 2000 and
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
of an object will be different in S-PLUS 6 than S-PLUS 2000
like vectors and matrices come to mind), but the behaviour
Well, I'm not sucking this out of my thumb. I see this
phenomenon. I know the
reason for it may be something else than the behavior of
platforms. I am trying to understand what causes this. I don't
need anyone
telling me that it is not true.
And if I have a statement like 'return(list(a=bla, b=blabla)'
inside a 'tapply' then on the PC version I can
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
OK I'm just stirring some BS. Nevertheless I have observed
this and solved it
by using the [[ ]] notation.
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
Like many aspects of the S language, the behaviour of
quirky, but it is consistent. In S-PLUS 6 you can turn off
coercieon with the options(stringsAsFactors=F). If your
doubles, there must have been a text character there
been converted to a factor.
Well no, the whole column is in the scientific notation, with
a possible NA
somewhere. So, it could be that an NA is read by read.table()
as a character,
explaining this, but that is, in my opinion, not the desired
behavior. If Splus
supports NA, which is great, it should support it everywhere.
thanks
Sicco
**********************************************************************
Any information in this communication which is confidential must not
be disclosed to others without our consent. Such consent is
not required
where the information is publicly available and intended for onward
distribution. If the information is confidential and if you
are not the
intended recipient, you are not authorised to and must not disclose,
copy, distribute, or retain this message or any part of it. You are
requested to return this message to the sender immediately.
Due to the electronic nature of e-mail, there is a risk that the
information contained in this message has been modified.
Consequently Man Investment Products can accept no responsibility or
liability as to the completeness or accuracy of the information.
Visit us at: www.maninvestmentproducts.com
**********************************************************************
---------------------------------------------------------------------
This message was distributed by s-news at lists.biostat.wustl.edu. To
unsubscribe send e-mail to
s-news-request at lists.biostat.wustl.edu with
the BODY of the message: unsubscribe s-news
---------------------------------------------------------------------
This message was distributed by s-news at lists.biostat.wustl.edu. To
unsubscribe send e-mail to s-news-request at lists.biostat.wustl.edu with
the BODY of the message: unsubscribe s-news