similar to: dimname'less array breaks apply (PR#318)

Displaying 20 results from an estimated 20000 matches similar to: "dimname'less array breaks apply (PR#318)"

2010 Jul 29
1
Using 'dimname names' in aperm() and apply()
I think that the "dimname names" of tables and arrays could make aperm() and apply() (and probably some other functions) easier to use. (dimname names are, for example, created by table() ) The use would be something like: -- x <-table( from=sample(3,100,rep=T), to=sample(5,100,rep=T)) trans <- x / apply(x,"from",sum) y <- aperm( trans,
2017 Jan 26
3
RFC: tapply(*, ..., init.value = NA)
Last week, we've talked here about "xtabs(), factors and NAs", -> https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html In the mean time, I've spent several hours on the issue and also committed changes to R-devel "in two iterations". In the case there is a *Left* hand side part to xtabs() formula, see the help page example using 'esoph', it
2017 Jan 27
1
RFC: tapply(*, ..., init.value = NA)
The "no factor combination" case is distinguishable by 'tapply' with simplify=FALSE. > D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), N=3) > D2 <- D2[-c(1,5), ] > DN <- D2; DN[1,"N"] <- NA > with(DN, tapply(N, list(n,L), FUN=sum, simplify=FALSE)) A B C D E F 1 NA 6 NULL NULL NULL NULL 2 NULL NULL 3 6
2017 Jan 26
2
RFC: tapply(*, ..., init.value = NA)
On a related note, the storage mode should try to match ans[[1]] (or unlist:ed and) when allocating 'ansmat' to avoid coercion and hence a full copy. Henrik On Jan 26, 2017 07:50, "William Dunlap via R-devel" <r-devel at r-project.org> wrote: It would be cool if the default for tapply's init.value could be FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE
2000 Mar 26
1
matlines, matpoints don't follow prototype (PR#506)
The Blue Book allows the 'type' argument to be used in matpoints and matlines. matlines(x, y, type="l", lty=1:5, pch=, col=1:4) R-1.0.0 does not. Thus, type="h", "b", must be invoked thru matplot( x, y, type = "h", add=TRUE) For the sake of consistency with S, it would be nice to have matlines defined as: "matlines" <-
2001 Oct 08
1
NA as names of vector from subscripted matrix == bug ?
Is this a bug? > matrix(1:4,nc=2,dimnames=list(1:2,1:2))[c(1,3)] 1 NA 1 3 It has some annoying consequences, e.g. > median( matrix(1:9,nc=3,dimnames=list(1:3,1:3))[1,,drop=F] ) NA 4 > The above was for Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status = major = 1 minor = 3.0 year = 2001 month = 06 day = 22
2000 Mar 22
3
segmentation fault with 1D array (PR#500)
Here's a nasty one. The following has caused a segmentation fault and possibly also a bus error. fred <- 1:6 dim(fred) <- 6 dimnames(fred) <- list(LETTERS[1:6]) mm <- matrix(1:12, 2, 6) mm %*% fred # segmentation fault here In the case without the dimnames assignment the result is OK. Cheers, Jonathan. --please do not edit the information below-- Version: platform =
2000 Sep 23
3
bug in apply with median
I have found a problem in R version 1.1.1 when using apply with the median function. The problem can be illustrated with the following data matrix: X1 X2 X3 1 2 3 4 5 6 7 8 NA Enter this data matrix as X and then try apply(X,2,median,na.rm=T) The problem here is that the median function returns a named scalar if the number of observations is odd, but returns an
2006 Mar 27
1
Safe to UNPROTECT() when object is assigned to a list?
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
2008 Apr 15
1
by inconsistently strips class - with fix
summary: The function 'by' inconsistently strips class from the data to which it is applied. quick reason: tapply strips class when simplify is set to TRUE (the default) due to the class stripping behaviour of unlist. quick answer: This can be fixed by invoking tapply with simplify=FALSE, or changing tapply to use do.call(c instead of unlist executable example:
2001 Nov 29
1
rug(x) clip warning incorrect if par("xlog")==TRUE (PR#1188)
To wit: > plot(1:2,1:2,log="x") > rug(1:2) # should not warn Warning message: some values will be clipped in: rug(1:2) > plot(1:2,1:2,log="x") > rug(c(0,.1,.2)) # should warn, but does not > I believe this fixes the problem: % diff -c /tmp/orig.rug.R /tmp/cberry.rug.R *** /tmp/orig.rug.R Thu Nov 29 12:59:00 2001 --- /tmp/cberry.rug.R Thu Nov 29
2004 May 10
7
strange behavior of names<-
Dear R-help, I've encounter what seems to me a strange problem with "names<-". Suppose I define the function: fun <- function(x, f) { m <- tapply(x, f, mean) ans <- x - m[match(f, unique(f))] names(ans) <- names(x) ans } which subtract out the means of `x' grouped by `f' (which is the same as, e.g., resid(lm(x~f)) if `f' is a factor).
1997 Dec 08
3
R-alpha: Bug in tapply in the Windows version of September
The function tapply is not working in the Windows version of R=20 (Version 0.50 Beta (Sept 29, 1997)) In tapply <- function (x, INDEX, FUN=3DNULL, simplify=3DTRUE, ...)=20 ... The part: if (simplify && all(unlist(lapply(ans, length)) =3D=3D 1)) { ans <- unlist(ans, recursive =3D FALSE) names(ans)<-namelist[[1]] return(ans) } should be replaced by if (simplify
2017 Jan 27
1
RFC: tapply(*, ..., init.value = NA)
On Fri, Jan 27, 2017 at 12:34 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > > On Jan 26, 2017 07:50, "William Dunlap via R-devel" <r-devel at r-project.org> > > wrote: > > > It would be cool if the default for tapply's init.value could be > > FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for >
2013 Aug 09
1
a fast table() for the 1D case
Hi, table1D() below can be up to 60x faster than base::table() for the 1D case. Here are the detailed speedups compared to base::table(). o With a logical vector of length 5M: 11x faster (or more if 'useNA="always"') o With factor/integer/numeric/character of length 1M and 9 levels (or 9 distinct values for non-factors):
2001 Apr 30
1
Segmentation fault linked to memory? (PR#929)
Hi Everyone, The following rather extreme claim on memory causes a segmentation fault on my installation: fred <- matrix(1:1200, 20, 60) littleOP <- function(x, y) { z <- as.vector(x) %*% t(as.vector(y)) dim(z) <- c(dim(x), dim(y)) z } littleOP(fred, fred) # this is OK littleOP(littleOP(fred, fred), fred) # whoops! Segmentation fault What's a bit strange
2000 Feb 17
2
"a.matrix[a.char.matrix]<- " crashes R (PR#447)
To wit: --- > junk <- array(3,c(10,3),dimnames=list(as.character(1:10),as.character(1:3))) > junk[cbind(as.character(1:5),as.character(c(1,2,3,2,3)))] <- 20 > > junk Process R segmentation violation (core dumped) at Wed Feb 16 15:57:49 2000 --- I know that the use of a ***character*** matrix is not documented for this context. Still, it should not crash R. In addition to
2004 Aug 30
0
small bug in apply() ??? (PR#7205)
System: R 1.9.1 on Windows 2000. Description of problem: So far as I can tell, this occurs only when using apply() on an array of dimension >=3 AND when for each iteration the function returns a named vector of length >=2. I propose the source of the bug and the fix below, but let me stick to the facts first. Here is an example: >a<-array(1:24, dim=2:4) >
2005 Aug 22
2
problem building dendrograms to use with heatmap()
Hi, I'm trying to build dendrograms to pass to heatmap(). The dendrograms I build plot properly, but when I pass them to heatmap() I get the error message "row dendrogram ordering gave index of wrong length" (see output log below). I looked in the code of heatmap() and saw that the error was due to a NULL return value from order.dendrogram(), which in turn got a NULL return value
2013 Feb 23
2
assign index to colnames(matrix)
Hello, I’m trying to follow the syntax of a script from a journal website. In order to create a regression formula used later in the script, the regression matrix must have column names “X1”, “X2”, etc. I have tried to assign these column names to my matrix ScoutRSM.mat using a for loop, but I don’t know how to interpret the error message. Suggestions? Thanks, Paul