similar to: as.data.frame(NULL) & as.data.frame(list()) & bug in dput(.)

This is not only bug report, but also a RFC (request for comments): The basic problem is that there are (at least) two ways of easily getting non-factor character columns in data.frames. The first is read.table(*, as.is = TRUE) and the second is data.frame(.., I(...), ..) which differ in their result. Whereas the first produces `pure' character columns in the data.frame,

>>>>> "WoKo" == Wolfgang Koller <koller2@fgr.wu-wien.ac.at> writes: WoKo> Hi! The postscript device in 0.90 does not produce symbols WoKo> (pch=) as it should. E.g.: WoKo> postscript(file="test.ps",width=8,height=6.4,horizontal=FALSE) WoKo> plot(1:10,1:10,pch=1:5) WoKo> legend(1,9,letters[1:5],pch=1:5) WoKo>

gives an error in R. In both S+3 and S+5, it "works" by returning NULL or logical(0), respectively. As a consequence, all(x == y) returns TRUE in Splus, when x <- y <- NULL but gives an error in R. Do we have a good reason *not* to return logical(0) ? Martin Maechler <maechler@stat.math.ethz.ch> http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO

I don't have time now to investigate myself, and I'm not feeling like deciding myself if the following is a bug: myplot <- function(dat, cex = 1.2, ...) { if(!is.data.frame(dat <- as.data.frame(dat))) stop("`dat' must be a data.frame") if(any(is.na(match(c("x","y"), names(dat))))) stop("`dat' must have a `x' and a

In S-plus (5.1), > cbind(data.frame(x=1,y=2), data.frame(x=4,u=3)) x y x1 u 1 1 2 4 3 whereas in R, the 3rd name is "x", the same as the 1st one. I think R should behave the same as S+5.1.. Martin Maechler <maechler@stat.math.ethz.ch> http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO D10 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich

Short example: > str(d <- data.frame(a = I(letters[1:5]))) `data.frame': 5 obs. of 1 variable: $ a:Class 'AsIs' chr [1:5] "a" "b" "c" "d" ... > str(d[TRUE,,drop = FALSE]) `data.frame': 5 obs. of 1 variable: $ a: chr "a" "b" "c" "d" ... The real problem about this is, that as soon

Thank you Bendix, {I hope it's okay if I CC my answer to your private mail to R-devel ..} >>>>> On Wed, 27 Oct 1999 08:55:28 +0200, BXC@novo.dk (Bendix Carstensen) said: >> -----Original Message----- >> From: Martin Maechler [mailto:maechler@stat.math.ethz.ch] >> Sent: 25. oktober 1999 14:58 To:Gregory R. Warnes >> Cc:

MM> I've sent two bug reports that both haven't been forwarded to R-devel MM> and haven't should up at the jitterbug repository. MM> ?? MM> Martin Well, actually only one [the other went to R-core alone] Here it is : From: Martin Maechler <maechler@sophie> To: R-bugs Subject: plot math - segfault and "frac", "^" bug(s).. Date: 8

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: MM> This is not a bug in the very strict sense, MM> but for consistency, MM> I feel that MM> abline() MM> should obey par("xpd") setting, even by ...-argument. MM> The following code shows how lines() ``works'' and abline() does not :

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: >>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes: TL> On Thu, 24 Aug 2000, Troels Ring wrote: >>> Dear friends. >>> >>> Is this as expected ? Is alpha and beta too large simply ? >>>

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: >>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes: TL> On Thu, 24 Aug 2000, Troels Ring wrote: >>> Dear friends. >>> >>> Is this as expected ? Is alpha and beta too large simply ? >>>

>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch> writes: >>>>> "david" == david <david@orion-10.cs.byu.edu> writes: david> When I issue the command: if ( c(2.8,3)[1] < pretty david> (c(2.8,3))[1]) print ("problem") david> the result is "problem" prints. I have traced it to bits

>>>>> "FrSa" == SABIDO =?iso-8859-1?Q?MART=CDN?= <SABIDO> writes: FrSa> Hello. I am a student from Spain. We are working on 'R' (a FrSa> programming environment for data analysis and graphics). Our FrSa> teacher has told as to make a job about tests in non complet rank FrSa> linear regresion models (I hope you could understand

Our sys.admin fixed one important (NIS) problem and accidentally simultaneously badly broke part of sendmail's functioning. Unfortunately, this lasted ~ 40 minutes, and somehow sendmail just "thought" it had to resend these messages several times (up to 8 x) that came in during that 40 minutes' period. Accept our (math.ethz.ch)'s apologies... Martin Maechler <maechler

(as the subject says) It makes sense to add (say k) boxplots to a given plot, using the given coordinate system. Currently, the calling sequence boxplot -> boxplot.default() -> bxp() [modeled after S] doesn't allow this, since bxp() explicitly sets up the coordinate system. One way would be to add an "add = TRUE" argument to boxplot(.) and bxp(.) and then additionally

This is something between a question and a bug report. {sometimes one should first ask on R-help before sending to R-bugs....} I wanted to plot (.) a formula with "..." ## Works : e0 <- expression(T(x[1],...x[n])*", "*N[1] == 101) # works ok plot(1, main = e0) ## Now, need substitute, to replace with value of variableThis works nn <- 102 (e1 <-

>>>>> "TL" == Thomas Lumley <thomas at biostat.washington.edu> writes: TL> I'm receiving duplicates of a number of old r-help messages, all with TL> headers having the rly-mx2.maxis.net.my section in the message below. Is TL> this at your end? Do you know about it? Doug Bates has averted me; and I have since stopped these to be propagated

Not many of you will use grid() widely, probably. Also, two months ago, Paul Murrell said on R-help (topic "grid command") PM>> i think the abline() solution is the best for doing what grid() won't. PM>> like you say, grid() is just a simple front-end to abline(). grid() *is* too simple to be of practical use. I propose the following which is of some practical

(R 0.65.0 and earlier): example(aov) lm.influence(npk.aov) gives Error: NA/NaN/Inf in foreign function call (arg 6) which comes from the lm.obj$coefficients (the last 3-way interaction coefficient is indetermined and accordingly NA) argument passed to .Fortran("lminfl",...) inside lm.influence. The following is a simple correct patch --- lm.influence.R 1999/08/13

Something worth discussing, I think these output names NEED a change : > boxplot(rt(250,df=3), plot=F) $"1" $"1"$stats [1] -2.7995357 -0.7170382 0.1109581 0.8426811 3.0483316 $"1"$n [1] 250 $"1"$conf [1] -0.04490152 0.26681765 $"1"$out [1] 5.784389 4.766206 -3.932449 -3.460407 -3.695599