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@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 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
>
> **********************************************************************
>
> ---------------------------------------------------------------------
> 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
>
|