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 time for all
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@asml.com]
>Sent: Thursday, September 27, 2001 10:32 AM
>To: David Smith
>Cc: s-news@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
>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.
>
>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
>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.
>
>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
>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.
>
>Not true!
>
>>
>>
>> > 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.
>
>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 mode() between
>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 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).
>
>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
>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.
>
>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
**********************************************************************
|