[Bioc-devel] Use of Matrix inside SummarizedExperiment
Thanks, Herv?!
On 26/01/2016, Herv? Pag?s <hpages at fredhutch.org> wrote:
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, H.
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