[Bioc-devel] Use of Matrix inside SummarizedExperiment

Hervé Pagès hpages at fredhutch.org
Tue Jan 26 08:12:31 CET 2016

Hi Pete,

On 01/25/2016 12:32 PM, Peter Hickey wrote:
> The Matrix virtual class in the Matrix package seems to mostly work as
> an assays element in a SummarizedExperiment. This is especially useful
> for data that can be efficiently represented as a sparse matrix, e.g.,
> using the dgCMatrix class.
> My understanding is that this works because the (concrete subclasses
> of) Matrix implement the necessary basic S4 methods to form a basic,
> matrix-like API. However, there are a couple of edge cases that I'm
> hoping it might be possible to smoothen out. Ideally, I'd love if this
> could work for any class that implements a minimal matrix-like API
> (I'm currently experimenting with such a class) and not just for the
> Matrix virtual class and its concrete subclasses. From reading the
> SummarizedExperiment code, it looks like the minimal methods required
> for an element of a (concrete subclass of) Assays object would be dim,
> dimnames, [, [<-, rbind, cbind, length. I suppose that if any
> additional methods are added for the Assays virtual class (e.g., I
> have an almost-complete combine,SummarizedExperiment-method that calls
> a combine,Assays-method) then these matrix-like objects must also have
> such methods defined to ensure relatively straightforward inheritance.
> Here are a couple of instances where a matrix and a Matrix behave
> (understandably) differently but where it would be nice if it "just
> worked". There may well be others, but I'd be interested to know
> whether this is worth further pursuing.
> library(SummarizedExperiment)
> library(Matrix)
> m <- matrix(1:10, ncol = 2)
> m2 <- Matrix(m)
> # SummarizedExperiment constructor has specialised matrix method.
> se <- SummarizedExperiment(m)
> # This won't work because there is no Matrix specialisation
> se2 <- SummarizedExperiment(m2)
> # But can get around this by wrapping the Matrix in a SimpleList to defer to
> # the SummarizedExperiment,SimpleList-method
> se2 <- SummarizedExperiment(SimpleList(m2))

Note that wrapping the Matrix in an ordinary list also works.

> # I guess the only way around this is to write a SummarizedExperiment method
> # for every matrix-like class, which might be too much overhead for the
> # SummarizedExperiment package to maintain. Perhaps there is another solution,
> # e.g., try wrapping the input in a call to SimpleList if no method found and
> # then deferring to the SimpleList method? Could be too messy to be worth it ...

The method for matrix already does this wrapping into a SimpleList
object and then defers to the method for SimpleList method. I just
replaced the current method for matrix by a method for ANY that does
exactly the same thing. With this change, SummarizedExperiment() takes
any matrix-like object.

> # assay<- dispatches on value (which must be a matrix)
> assay(se) <- assay(se)
> # Won't work because there is no Matrix specialisation
> assay(se2) <- assay(se2)
> # But using assays() does work
> assays(se2)[[1]] <- assays(se2)[[1]]
> # Could value be dropped from the assay<- signatuare and the object validated
> # during/following the consequent call to assays<-?

That makes a lot of sense. Having the assay() setter dispatch on 'x',
'i', and 'value' has no real benefit. Dispatching on 'x' and 'i' is
enough and allows the assay() setter to take any matrix-like object as
long as the resulting SummarizedExperiment object is valid.

These 2 changes are in SummarizedExperiment 1.1.17.

Thanks for the suggestions,

> Cheers,
> Pete
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

More information about the Bioc-devel mailing list