Re: [Bioc-devel] Use of Matrix inside SummarizedExperiment

2016-01-26 Thread Peter Hickey
Thanks, Hervé!

On 26/01/2016, Hervé Pagès  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@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

Re: [Bioc-devel] Use of Matrix inside SummarizedExperiment

2016-01-25 Thread Hervé Pagès

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