Re: [Rd] getMethods() not finding all methods

Hi Seth, Thanks for the info - actually one of the things I like about getMethods is seeing the function internals - as you point out, geneNames is being deprecated in favour of featureNames, which is revealed by the guts of the geneNames method ;) > getMethods("geneNames") An object of class “M

Re: [Rd] getMethods() not finding all methods

"Steven McKinney" <[EMAIL PROTECTED]> writes: > Running R2.4.0 on Apple Mac OS X 10.4.8, > in Emacs ESS mode, and also R.app. > > > In an attempt to learn a bit more about > a particular method (geneNames in package affy) > I invoked > > getMethods("geneNames") > > which produced geneNames metho

[Rd] getMethods() not finding all methods

Running R2.4.0 on Apple Mac OS X 10.4.8, in Emacs ESS mode, and also R.app. In an attempt to learn a bit more about a particular method (geneNames in package affy) I invoked getMethods("geneNames") which produced geneNames methods, but not the one in affy (output below). I had to know the

Re: [Rd] Should NA's in summary() output always be reported???

Søren, If you think summary() should report NA's, then it's better to post your question on r-devel list (r-devel@r-project.org ). I think that summary(1:5) is not reporting NA's because there is no NA in your data. For the same reason it's not reporting NaN's, Inf

[Rd] Should NA's in summary() output always be reported???

Consider > summary(1:5) Min. 1st Qu. MedianMean 3rd Qu.Max. 1 2 3 3 45 > summary(c(1:5,NA)) Min. 1st Qu. MedianMean 3rd Qu.Max.NA's 1 2 3 3 4 5 1 Wouldn't it be mor

Re: [Rd] Installation fails on FreeBSD (PR#9293)

Hi Peter, Okay, I've now fixed the problem. My /tmp directory was mounted with noexec -- so the configuration script couldn't run. >From a security point of view, it is always a dilemma if 'executables' should >be allowed to run in /tmp -- it's a favourite point for attacks. Anyway, I tem

Re: [Rd] data.frame within a function (PR#9294)

On 10/12/2006 1:45 PM, [EMAIL PROTECTED] wrote: > Full_Name: Riyan Cheng > Version: windows 2.0.1 This version is really quite ancient. The current release is 2.4.0. > OS: windows xp > Submission from: (NULL) (74.140.105.186) > > > > If one runs the following function ff(), an error would occ

[Rd] data.frame within a function (PR#9294)

Full_Name: Riyan Cheng Version: windows 2.0.1 OS: windows xp Submission from: (NULL) (74.140.105.186) If one runs the following function ff(), an error would occur regarding data.frame(): ff<- function(){ x<- rnorm(10) y<- rnorm(10) lm1<- lm(y~1,data=data.frame(y=y,x=x)); cat("o

Re: [Rd] [R] multithreading calling from the rpy Python package

Thanks, Duncan, > It is a mixture of two things. Yes, R is not thread safe so if > two system threads were to access R concurrently, bad things would > happen a.s. That's clear, yes. :-/ And a pity, but so be it. > It is also an issue when Python is compiled and linked with > threaded options

Re: [Rd] error in dput applied to dataframe (PR#9286)

The help for dput says Deparsing an object is difficult, and not always possible. With the default 'control = c("showAttributes")', 'dput()' attempts to deparse in a way that is readable, but for more complex or unusual objects, not likely to be parsed as identical to the

Re: [Rd] plot.POSIXct

On 10/12/2006 9:08 AM, Armstrong, Whit wrote: > I've never had any issues with the way that plot.POSIXct chooses the > labels of the date axis before, but in this particular case it's output > is a little confusing. It was wrong, but this was fixed in R-patched last week. I've added an item to N

Re: [Rd] plot.POSIXct

Sorry forgot to include: > R.Version() $platform [1] "x86_64-unknown-linux-gnu" $arch [1] "x86_64" $os [1] "linux-gnu" $system [1] "x86_64, linux-gnu" $status [1] "" $major [1] "2" $minor [1] "4.0" $year [1] "2006" $month [1] "10" $day [1] "03" $`svn rev` [1] "39566" $language [1] "R"

[Rd] plot.POSIXct

I've never had any issues with the way that plot.POSIXct chooses the labels of the date axis before, but in this particular case it's output is a little confusing. plot(seq(as.POSIXct("1997-10-01"),length.out=108,by="month"),rnorm(108)) This command produces a chart with every x tick mark labeled

Re: [Rd] Installation fails on FreeBSD (PR#9293)

Hi Peter, Hmm, I thought so as well -- and so I did a chown and a chmod and set umask to and still the problem persists. Then I went wild and tried doing it as root, and still the problem remains. So, I've now deleted everything in the ports tree and am kicking off the make again. But s

Re: [Rd] Installation fails on FreeBSD (PR#9293)

[EMAIL PROTECTED] writes: > Full_Name: Peter Smith > Version: 2.3.1 > OS: FreeBSD 5.3 > Submission from: (NULL) (219.88.191.10) > > > I'm installing R from the FreeBSD ports tree (i.e. running make from > /usr/ports/math/R). During the make, the following error message is generated. > > >

[Rd] Installation fails on FreeBSD (PR#9293)

Full_Name: Peter Smith Version: 2.3.1 OS: FreeBSD 5.3 Submission from: (NULL) (219.88.191.10) I'm installing R from the FreeBSD ports tree (i.e. running make from /usr/ports/math/R). During the make, the following error message is generated. Formats: text html latex example >>> Building/

Re: [Rd] Bug in 2.4.0 Windows menu setup (PR#9277)

Prof Brian Ripley wrote: On Fri, 6 Oct 2006, Duncan Murdoch wrote: On 10/6/2006 1:35 PM, Hin-Tak Leung wrote: I would propose correcting the encoding of the *content*, rather than the charset tag, so that Rgui-* all uses localised ones (CP932, CP936, CP949, CP950). That should be better for

Re: [Rd] Bug in 2.4.0 Windows menu setup (PR#9277)

On Fri, 6 Oct 2006, Duncan Murdoch wrote: > On 10/6/2006 1:35 PM, Hin-Tak Leung wrote: >> Duncan Murdoch wrote: >>> On 2006-10-5 8:06, Ei-ji Nakama wrote: I do not understand Chinese, but recognize kanji. RGui-zh_CN.po is written in utf-8, but charset=CP936 wrote. perl -p -i