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