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@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: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
