similar to: "[.data.frame" forgets about "AsIs" (PR#665)

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,

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

In several places, we have the convention that col = NA means `` don't draw '', e.g. for points() or rect(). For col = <vector> this only works when the vector is integer (numeric), but not in other cases. I think this is a bug, even though not in the strict sense, since we don't seem to claim it should work.. Example: plot(1:10, col = c(1:4,NA,NA,4:1)) ## fine

I would want to know if it's possible to plot two histograms on the same graphic in order to compare the bins one to one, like a Excel graphic. If it is possible can you help me to do it, because I don't know the exact R-commands. Thanks for your help Damiano > > >Martin Maechler <maechler at stat.math.ethz.ch> http://stat.ethz.ch/~maechler/ >Seminar fuer Statistik,

>>>>> "TL" == Thomas Lumley <thomas@biostat.washington.edu> writes: on Subject: Re: [Rd] Problem with NAs using chisq.test() (PR#748) which I've changed, since it is another bug we are talking about now TL> On Sun, 26 Nov 2000 kjetikj@astro.uio.no wrote: >> Full_Name: Kjetil Kjernsmo .............. .............. TL> However,

A colleague has a dozen of excel sheets and also expects to get updates regularly. He could open these in M$-Excel and export as *.csv manually, "bring back to Unix" and then read into R. Of course there must be options to start programming this in something like visual basic, but we wouldn't to really want to... We also know that probably Gnumeric could do the job (since the xls

As many of you have probably realized, the spam filtering at @stat.math.ethz.ch has been dead for since yesterday (09-25) ~16:50 till today ~08:30. The sudden death may have been caused by unrelated installation of some perl modules (spamassassin *is* running on perl) by our IT staff. We are very sorry for this event. On the bright side: You have been able to get a glimpse of what you are

Many of us known that sometimes, e.g. in calls to .C(..), you want to basically say x <- as.integer(x) but you can't do that because as.vector() and it's descendants such as as.integer, as.double, as.character drop all attributes. Several months ago, someone proposed to use a new function As.integer() instead. Since I just now again "stumbled" on it, I wondered if

We have locally collected good experience the last few weeks using procmail-spam filtering, inclduing spamassassin to the procmail filters. The last two spams that went past the majordomo filters (the "traditional ones I've been using) through to R-devel both were not delivered to me, be but caught by the filters. I have now collected a bit more of a week experience using the new scheme

In some contexts, I find the current behavior of rank() very `suboptimal'. We have the argument na.last = {TRUE | FALSE | NA } where the first two cases treating NAs (almost) as if they were == +Inf or == -Inf whereas the 3rd case just drops NAs. For the typical ``Rank Transformation'' that is recommended in EDA in several contexts, I would however want something else, namely keep

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

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

In nonparametric regression and density estimation, something like \hat{f'}(x) [LaTeX] is very natural. In all S dialects, hat(f') is invalid syntax, and hence one cannot use something like plot(1, main = expression(hat(f'))) I can say something like plot(1, main = expression(widehat(paste(f, "'"))), cex.main = 3) but that (the R code, not the plot result)

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

{Connected to the bug report on expand.grid(.) and my fix to it..} [Following the spirt of arrays where parts of dim() can be 0] I would like for these two to give the "same" or at least, both to give a data.frame with 0 observations of 0 variables. Currently [R 0.65.1 and pre-0.90] > str(d0 <- as.data.frame(list())) `data.frame': 0 obs. of 0 variable: list()

Dear all, The following causes me trouble: > a <- data.frame(2:5,3:6,4:7) > str(a) `data.frame': 4 obs. of 3 variables: $ X2.5: int 2 3 4 5 $ X3.6: int 3 4 5 6 $ X4.7: int 4 5 6 7 > str(data.matrix(a)) int [1:4, 1:3] 2 3 4 5 3 4 5 6 4 5 ... - attr(*, "dimnames")=List of 2 ..$ : chr [1:4] "1" "2" "3" "4" ..$ : chr

getenv(<varname>) currently returns "" if the <varname> is undefined. However, if <varname> is defined but empty, getenv(<varname>) still only returns "". I think this is quite unfortunate but consistent with the prototype. --- I'd propose to change the current behavior. Something which should be pretty back compatible would for the first

I don't know if we still strive for non-GNU make capability.. Anyway, here a report: I was using the builddir != srcdir approach on Sun Solaris 2.6, and normal Sun make (/usr/ccs/bin/make) worked up to producing a correct R.X11 binary. It failed when trying to make the first src/library/<pkg>/src/<pkg>.so, namely in eda/src with make: Fatal error: Don't know how to make

Here's an example (session info at the end). > tmpv <- c('\265g/L','Bq/L') > order(tmpv) [1] 2 1 > tmpv <- I(tmpv) > order(tmpv) Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed > foov <- gsub('\265','',tmpv) > order(foov) [1] 2 1 > str(tmpv) Class 'AsIs' chr [1:2] "\265g/L"

We have (spatial statistics) group here that are (about to) interface Fortran 90 and/or 95 software to R and/or S-plus. My recommendation has been against this because of non-availability of GNU or other free (not only moneywise, in the GNU sense) compilers for Fortran 9x. Does anybody have good guesses about the future here? The user group here say they like F 9[05] because of its ``object