similar to: deparse drops () sometimes (PR#169)

I bumped into the following situation: Browse[1]> coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept) 462 510 528 492 660 762 Browse[1]> coef[,1] [1] 462 Browse[1]> coef[,1,drop=F] deg0NA (Intercept) 462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of

One of the things that have been annoying me with both Splus and R is that the "simple tests" are inconsistent with the lm/glm/dataframe conventions, and that they become quite awkward to use when data have to be extracted from a dataframe: t.test(data$bp[data$sex=="F" & data$age>25], data$bp[data$sex=="M" & data$age>25]) OK, so it's better to do

I promised R-core write-up of my understanding of the comment placement nastiness, but I might as well increase the scope to R-devel: (R moves, mangles, or deletes comments in mysterious ways -- see for instance PR#118) One basic issue is that any R parse tree can have 0, 1, or more textual representations. Examples quote(x) # one, presumably... substitute(+x,x=list(1:2)) #

If I'm not mistaken, "bundle" is really only useful as a concept for distribution and installation. You distribute and install a bundle, but load the individual packages when you want to use them. Once you install the bundle, you won't see the name of the bundle in the list of installed packages, but you see the constituent packages, and those are what you load when you want to

I agree with the the comments below on "Numerical recipes". We developed some commercial software using the code and tried to get a licence. They never responded to our corresponce :-) We also mailed them fixes to some bugs !!! but never heard anything. So we threw their code away and wrote our own... it was a waste of time using the book. Kim On Thursday, 25 November 1999 6:41,

For small datasets it would be useful to be able to copy a block of data from a spreadsheet then toggle over to R and just paste it in. If it's possible, having read.table access the clipboard (e.g. x <- read.table(file="clipboard", ...) would do the trick. Of course, exporting to a file and the reading into R is pretty easy but usring the clipboard would save a couple extra

I've put up R-0.63.1.tgz up for FTP from Auckland some minutes ago. As usual, don't get it from there unless you are desperate, but wait for it to be mirrored at a CRAN site near you within a day or two. For those who *are* desperate, I've left a copy in ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.63.1.tgz (Be gentle, that's my desktop PC!) The person who fetched R-0.63 *from

I've put up R-0.63.1.tgz up for FTP from Auckland some minutes ago. As usual, don't get it from there unless you are desperate, but wait for it to be mirrored at a CRAN site near you within a day or two. For those who *are* desperate, I've left a copy in ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.63.1.tgz (Be gentle, that's my desktop PC!) The person who fetched R-0.63 *from

bhoel@server.python.net (Berthold Höllmann) writes: > Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes: > > > I've rolled up R-1.0.0.tgz a short while ago. > > > I've build R-1.0.0 on my > > >uname -a > Linux pchoel 2.2.14 #3 Mit Jan 5 08:57:39 MET 2000 i686 unknown > > box. Calling "make check" fails with .... > >

bhoel@server.python.net (Berthold Höllmann) writes: > Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes: > > > I've rolled up R-1.0.0.tgz a short while ago. > > > I've build R-1.0.0 on my > > >uname -a > Linux pchoel 2.2.14 #3 Mit Jan 5 08:57:39 MET 2000 i686 unknown > > box. Calling "make check" fails with .... > >

I'm happy to announce that there is now a real bug tracking system for R. Hopefully, this will make it easier for us to keep track of unresolved bugs, which has been difficult because of the massive amount of email that we receive. The system, which is of the JitterBug variety is available through the web at http://r-bugs.biostat.ku.dk or via email to r-bugs at biostat.ku.dk (which is

I'm happy to announce that there is now a real bug tracking system for R. Hopefully, this will make it easier for us to keep track of unresolved bugs, which has been difficult because of the massive amount of email that we receive. The system, which is of the JitterBug variety is available through the web at http://r-bugs.biostat.ku.dk or via email to r-bugs at biostat.ku.dk (which is

I'm happy to announce that there is now a real bug tracking system for R. Hopefully, this will make it easier for us to keep track of unresolved bugs, which has been difficult because of the massive amount of email that we receive. The system, which is of the JitterBug variety is available through the web at http://r-bugs.biostat.ku.dk or via email to r-bugs at biostat.ku.dk (which is

TASK: problem with "glm" with binomial errors STATUS: Open FROM: p.dalgaard@kubism.ku.dk in glm(,binomial) it's possible that loss of significant digits make expected values 0 or 1 even though there's no divergence of the fit. (Happened to me with menarche data, infants and grown-ups included) [ Need the example data. Glm needs a

I can confirm this bug has been solved, by the expedient of removing the incorrect functions! I think the simplest way to get a bug closed is to send the correction to the original reporter for confirmation, then as Peter suggests send a follow-up to R-bugs. On Fri, 6 Apr 2001 p.dalgaard@biostat.ku.dk wrote: > Paul Gilbert <pgilbert@bank-banque-canada.ca> writes: > > > Peter

OK folks, We're warming up to the release of R-2.0.0 on Oct. 4 (aka 2004-10-04). There will be two weeks of alpha releases followed by two weeks of beta releases, starting today. The releases are made available via CRAN in http://cran.r-project.org/src/base-prerelease and the first one is there already. In case of urgency or CRAN failure, the releases will also be found at

I've just gotten through translating my notes for the course in basic statistics for health researchers. I've placed a copy on ftp://blueberry.kubism.ku.dk/priv/R-intro.tgz This is essentially a translation of the Danish notes that I wrote during the Autumn of 1997 for use with Rsept, i.e. roughly R v.50. They lean heavily on the textbook, Altman: Practical Statistics for Medical

Dear Peter, Thank you very much for your kind and helpful reply. As I mentioned in a followup email to r-bugs, indeed, one aspect of this issue is a (user specified) shorter stack than that expected by R -- I had only allowed 1 MB of stack space a long long time ago, and forgotten about it. Due to a glitch with r-bugs@r-project.org, I ended up submitting this bug twice, and your original

Thanks to Peter Dalgaard and Suchandra Thapa for answering my question! Before I settle on a particular option, I'd like to ask one more question if I may: Are there any practical advantages to compiling R to 64-bit vs 32-bit? Regards, Andy > -----Original Message----- > From: Peter Dalgaard BSA [mailto:p.dalgaard at biostat.ku.dk] > Sent: Thursday, April 18, 2002 4:19 PM > To:

> For those who *are* desperate, I've left a copy in > ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.64.0.tgz > (Be gentle, that's my desktop PC!) Well, *now* it's there anyway... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918