similar to: match.call problem (PR#813)

Matthew Wiener <mcw@ln.nimh.nih.gov> writes: > t1 <- data.frame(matrix(rnorm(16), nc=4)) > t1$X1 <- 1 > t1$X2 <- 2 > print(t1) > Error: dim<- length of dims do not match the length of object Well, it is prototype-compatible. Splus 5.3 does likewise. A way out is t1<-data.frame(unclass(t1)) However, we do seem to have a bug in the area: > t1 <-

Matthew Wiener <mcw@ln.nimh.nih.gov> writes: > t1 <- data.frame(matrix(rnorm(16), nc=4)) > t1$X1 <- 1 > t1$X2 <- 2 > print(t1) > Error: dim<- length of dims do not match the length of object Well, it is prototype-compatible. Splus 5.3 does likewise. A way out is t1<-data.frame(unclass(t1)) However, we do seem to have a bug in the area: > t1 <-

Call objects don't always behave as you'd expect. They're mostly list-like, but with exceptions: > f<-function(x,y,...)match.call(expand.dots=FALSE) > xx <- f(y=1,2,z=3,4) > dd <- xx$... > xx$... <- NULL > c(xx,dd) [[1]] f(x = 2, y = 1) $z [1] 3 [[3]] [1] 4 > as.call(c(as.list(xx),dd)) f(x = 2, y = 1, z = 3, 4) (Splus has this rather differently,

[sys.function fails sometimes (sorry, our mail system decide to throw away the original mail)] Yes, I bumped into something similar recently. The problem is that we only actually store the call in the context structure, not the function, so sys.function has to grab the call, take the 1st element, and reevaluate it in the parent frame. It is quite easy to think up examples where a second

Don MacQueen <macq@llnl.gov> writes: > When I run the example in R 1.6.2, and view it with gs, I get a good plot. > When I run the example in R 1.7.0, and view it with gs, I get a bad plot. > (run on the same host) > > My "bad plot" is as described by Stephen. ... > (followed by ~200000 lines of the same type, with slowly changing values) > > In the

"Marco Taboga" <mtaboga@tiscalinet.it> writes: > OK, it works. xlab and ylab had to be set properly. > If you want to see what actually goes on, try: > a<-chron(1:2000) > b<-1:2000 > plot(a,b,type="l") > One of the standard blunders with R's lazy evaluation and substitute is to change the value of part of a substitute expression before it

"Swinton, Jonathan" <Jonathan.Swinton@astrazeneca.com> writes: > # works as expected > > ac <- c('A','B'); > > identical(ac,ac[1:2]) > [1] TRUE > > #but > > af <- factor(ac) > > identical(af,af[1:2]) > [1] FALSE > > Any opinions? Did a cross-check with Splus and it doesn't do that , so I think it

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 .... > >

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

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

1) hist() does not take NA's. Incompatible with Splus, probably just a bug? 2) I do wish we could somehow get rid of the misfeatures of indexing with logical NA's: > table(juul$menarche,juul$tanner) I II III IV V No 221 43 32 14 2 Yes 1 1 5 26 202 > juul$menarche=="Yes"&juul$tanner=="I",] ...and you find yourself with a listing of 477

In a bug report from Nov.28 2000, Li Dongfeng writes: ----- I have found that the polyroot() function in R-1.1.1(both solaris and Win32 version) gives totally incorrect result. Here is the offending code: # Polyroot bug report: # from R-1.1.1 > sort(abs(polyroot(c(1,-2,1,0,0,0,0,0,0,0,0,0,-2,5,-2,0,0,0,0,0,0,0,0,0,1,-2)))) [1] 0.8758259 0.9486499 0.9731015 1.5419189 1.7466214 1.7535362

Just to update: What I originally thought was a glm problem appears to be a memory problem that occurs only when R is compiled with the DEC C compiler. Some variables that are still in use get clobbered during garbage collection. No problems if I compile with gcc though. I've made some attempts to see if I can identify a specific compiler optimization that is responsible, but so far no luck.

Kjetil Kjernsmo <kjetil.kjernsmo@astro.uio.no> writes: > On 8 Nov 2000, Peter Dalgaard BSA wrote: > > >I'm not at all happy with this: > > > >Solaris : > >> range(sapply(1:2000, function(n) mean(rpois(10000, 15.0)))) > >[1] 15.0524 15.3403 > > Hm, OK, so it isn't just me.... I guess it is time to file a bug report, > should I do it,

jlindsey at alpha.luc.ac.be writes: > The following is a bug or feature in recent versions. Try the > following with a clean workspace: > > y <- cbind(rpois(20,4),rpois(20,4)) > df <- data.frame(y=y,x=rnorm(20)) > colnames(df) > colnames(model.frame(y~x,data=df)) > > Now start over with a clean workspace and try > > df <-

Prof Brian Ripley <ripley@stats.ox.ac.uk> writes: > "[<-.zoffset" <- function(x, i, j, value) > { > if(!missing(i) && is.numeric(i)) i <- i+1 > if(!missing(j) && is.numeric(j)) j <- j+1 > NextMethod("[<-") > } > works in S but not in R. (Which I think is a bug.) I next tried Yup, there's a bug in there

Prof Brian D Ripley <ripley@stats.ox.ac.uk> writes: > According to ?system (R-release) > > system(command, intern=FALSE) > > but the actual syntax is function(call, intern = FALSE, trash.errors = > FALSE). > > So, is it `call' or `command', and what does `trash.errors' do? (I assume > it is intended to make stderr be ignored, but that would not

I'm not sure exactly where to point my finger with this one, but there is a nasty surprise to the unsuspecting user. There is no check on the length of the vector passed in the pch= argument to plot, it is just recycled as necessary: plot(1:10,1:10,pch=1:2) gives alternating circles and triangles. The nasty bits come up especially with plot.formula: x<-1:10;y<-1:10

Shortest example is this: > function()(g)() function () (g) It executes OK, but editing a function with one of these in will introduce an error in an uexpected place. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ -