[Rd] list/matrix chimera

[Seth Falcon]

"hadley wickham" <h.wickham at gmail.com> writes:

> On 4/10/07, Tony Plate <tplate at blackmesacapital.com> 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