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
Sicco.Schets.vcf
Description: Card for Sicco Schets
|