similar to: collapsing list of NULLs dimnames into a NULL

This message is in MIME format --_=XFMail.1.1.p0.Linux:971128122615:3052=_ Content-Type: text/plain; charset=us-ascii I have rounded up three buglets in R-0.50-a4. Two of them I can fix and a patch is supplied below. I hope this is useful for the current source (if these haven't been fixed already :) 1) cov cov() fails when it's argument is a matrix with one column and with column names

I'm using rpart to fit a tree using a large dataset: 7000 observations, 4651 variables. All but one of the variables (age) are binary. When I run the code: fit1 <- rpart(lowergi ~ ., data=dset,method="class") I get the error: Error in dimnames(X) <-list(dn[1L]], unlist(collabs, use.names=FALSE)) : Length of `dimnames' [2] not equal to array extent I have no idea

Hello List, I`m trying to make prediction using a bagged tree with the package ipred. I tried to follow the manual but I`m getting an error message. Also browsing through the list-archive I didn`t find any hint. Maybe someone can help me? selbag <- bagging(SOIL_UNIT ~., data=traindat.bin, coob=TRUE) Error in dimnames(X) <- list(dn[[1L]], unlist(collabs, use.names = FALSE)) :

Hello, After some fuzz testing I found a problem with Rf_isVector() function in R 3.5.0. Platform: Ubuntu 16.04 Compiler: Clang-4.0 (from Ubuntu's repository) + ASAN Crashing R code:

Dear All, trying to write a data.frame, containing Surv objects to a csv-file I get "Error in dimnames(X) <- list(dn[[1L]], unlist(collabs, use.names = FALSE)) : length of 'dimnames' [2] not equal to array extent". See example below. May be, I overlooked something, but I expected that also data.frames containing Surv objects may be written to csv files. Is there a

I have no recollection of the original rationale for as.data.frame.table, but I actually think it is fine as it is: The classifying _factors_ of a crosstable should be factors unless very specifically directed otherwise and that should not depend on the setting of an option that controls the conversion of character data. For as.data.frame.matrix, in contrast, it is the _content_ of the matrix

This bug was reported to r-devel by Martin Morgan on 13th May 2008 (original email pasted below). However I couldn't locate it in the bug tracker (with searches for row, col, as\.factor) It is still present in today's svn version (rev 47115). I hope I'm doing something useful by bringing it up again. I have not sent this to r-bugs, as I'm concerned that not locating it in the bug

Reporting a possible inconsistency or bug in handling stringsAsFactors in as.data.frame.table() Here is a simple test > options()$stringsAsFactors [1] TRUE > x<-c("a","b","c","a","b") > d<-as.data.frame(table(x)) > d x Freq 1 a 2 2 b 2 3 c 1 > class(d$x) [1] "factor" >

Hello: I am looking at "Writing R Extensions", subsection 3.6.4, using R 1.1.0, under NT4.0, with VC++ 6.0. Under these conditions I can use the first method given for coding the out() function, but not the second, which uses getAttrib() and setAttrib(). I hope that someone will tell me how this second method can also be made to work. Details follow, for anyone kind enough to help.

Hi, I have been studying the R manual on lists but cannot seem to create a simple R list in C - I keep on getting "'dimnames' applied to non-array" whenever I attempt to assign names to the list elements: Wanted output a list structure something like [ type="Bid", price=2.0, volume=1000 ] I can get up to a list of [ "Bid2, 2.0, 1000 ] But for the life of

Hi, I'm troubleshooting some native code on Windows that very occationally (and semi-randomly) crashes R. Already looked at "everything", I just want to double check that it is safe to UNPROTECT() allocated variables as soon as they are assigned to, say, a PROTECTed list. >From (R v2.3.0) Section 5.7.1 "Handling the effects of garbage collection" in "Writing R

As others already mentioned, in your example you are first creating an integer matrix and the coercing it to a double matrix by assigning (double) 1 to element [1,1]. However, even when correcting for this mistake, there is an extra copy created when using matrix(). Try this in a fresh vanilla R session: > print(gc()) used (Mb) gc trigger (Mb) max used (Mb) Ncells 136684 3.7

Full_Name: Hsiu-Khuern Tang Version: 1.3.0 OS: GNU/Linux (Debian unstable) Submission from: (NULL) (192.6.19.124) Hi all, I am not sure this is a bug rather than an intentional design, but here goes: If I do > a <- matrix(1:4, nrow=2) > dimnames(a)[[1]] <- c("a", "b") I get the following error message because dimnames(a) is NULL: Error: more elements

Hi, I have been trying glht() from multcomp package and contrast() from contrast package to test a contrast that I am interested in. With the following simulated dataset (fixed effect "type" with 3 levels (b, m, t), and random effect "batch" of 4 levels, a randomized block design with interaction), sometimes both glht() and contrast() worked and gave nearly the same p values;

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3738F.63DE3390 Content-Type: text/plain; charset="iso-8859-1" #I want to be able to create a new S4 class and read data into it using C code # Here is a very simple S4 object inheriting from "array", but with 5

Dear list. It is a known issue that accessing slots of S4 objects and in particular accessing .Data slots is slow in R. However, what surprises me are two things demonstrated in the code below (runnable with 'inline', my times are in the comments): - copying data out of a large 3x1e7 .Data slot into a matrix can be easily made 3-4 times faster than accessing a .Data slot which I believe

>>>>> Davis Vaughan via R-devel >>>>> on Thu, 21 Mar 2024 15:10:29 -0400 writes: > Hi all, > I recently learned that it is possible for > `as.data.frame.matrix()` to produce a data frame with 0 > columns that is also entirely missing a `names` attribute, > and I think this is a bug: > ``` # No `names`, weird! >

Hi Martin, Henrik, I actually like this change. Makes a lot of sense IMO that dim(x) <- dim(x) be a no-op, or, more generally, that foo(x) <- foo(x) be a no-op for any setter/getter combo. FWIW S4Arrays::set_dim() does that too. It also preserves the dimnames if the right value is only adding or dropping outermost (ineffective) dimensions: ??? > x <- array(1:6, dim=c(2,3,1),

I'm continuing my work on finding speedups in generalized inverse calculations in some simulations. It leads me back to .C and .Call, and some questions I've never been able to answer for myself. It may be I can push some calculations to LAPACK in or C BLAS, that's why I realized again I don't understand the call by reference or value semantics of .Call Why aren't users of

Hi! I have been coding a C-program which will read data from the netCDF format (a commonly used file format in the geophysical research community: see Unidata's URL for explanation: http://www.unidata.ucar.edu/packages/netcdf/), and have got to the point where I don't know what the error message mean. The C-program is called nc2r.c. When compiling the code, I get a number of warnings,