"hadley wickham" <[EMAIL PROTECTED]> writes: > On 4/10/07, Tony Plate <[EMAIL PROTECTED]> wrote: >> Aren't you just seeing the effect of drop=TRUE? (at least with the >> examples you give below -- they all pick out a submatrix with extent one >> on some dimension) >> >> AFAICT, matrices with a list as the underlying data work properly,
Yes, I guess so, although I'm surprised this is all that useful. My mental model is that a matrix is a vector with dimension and that as such all elements are of the same type. When a list is used for the underlying data, then this is still true in that each element is itself a list (at least according to vv[i]), but that is less useful -- even if you figure out to use [[, there is no guarantee what you will find there: vv = c(list(a=list(inner=1), b="foo", c=matrix(1, nrow=2, ncol=2)), as.list(1:7)) dim(vv) = c(2, 5) >> It can actually be useful sometimes to have a matrix (or array) of >> non-atomic objects Well if you say so. I'm not sure how useful it could be without knowing that each element is the same type -- perhaps a notion of a vector of S4 objects would be useful... >> -- wouldn't your proposed change remove (or at least >> damage) that functionality? Yes, and it would not avoid the confusion that generated this post as cbind is documented to do what it does when given lists. So, with apologies for the noise, please ignore my suggestion regarding the behavior of R_data_class. > I use this functionality a lot in the reshape package. I would hate > to see it go! > > It would be nice to have some way to remove the [[1]] from vv[1, > 2][[1]] though. For lists, there is no guaranteed structure and so you can't avoid [[1]] since [1] will return a list and it can contain *anything*. What could be useful is the notion of a vector of S4 objects. There you could ensure they are all the same type. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel