[Bioc-devel] Virtual class for `matrix` and `DelayedArray`? (or better strategy for dealing with them both)

Hervé Pagès hpages at fredhutch.org
Mon Apr 30 20:35:03 CEST 2018


The class union should probably be:

   setClassUnion("matrixOrDelayed", c("matrix", "DelayedMatrix"))

i.e. use DelayedMatrix instead of DelayedArray.

So in addition to the class union and to Stephanie's solution, which
IMO are both valid solutions, you could also go for something like this:

myNewRowMeans <- function(x,...)
{
     if (length(dim(x)) != 2)
         stop("'x' must be a matrix-like object")
     ...
)

that is, just a regular function that checks that 'x' is matrix-like
based on its number of dimensions. If you really want to restrict to
matrix and DelayedMatrix only, replace the test with

     if (!(is.matrix(x) || is(x, "DelayedMatrix")))
         stop("'x' must be a matrix or DelayedMatrix object")

The difference being that now the function will reject matrix-like
objects that are not matrix or DelayedMatrix objects (e.g. a Matrix
derivative from the Matrix package).

Cheers,
H.


On 04/30/2018 09:29 AM, Stephanie M. Gogarten wrote:
> Rather than a class union, how about an internal function that is called 
> by the methods for both matrix and DelayedArray:
> 
> 
> setGeneric("myNewRowMeans", function(x,...) { 
> standardGeneric("myNewRowMeans")})
> 
> #' @importFrom DelayedArray rowMeans
> .myNewRowMeans <- function(x,...){
>      # a lot of code independent of x
>      print("This is a lot of code shared regardless of class of x\n")
>      # a lot of code that depends on x, but is dispatched by the 
> functions called
>      out<-rowMeans(x)
>      #a lot of code based on output of out
>      out<-out+1
>      return(out)
> }
> 
> setMethod("myNewRowMeans",
>            signature = "matrix",
>            definition = function(x,...){
>                .myNewRowMeans(x,...)
>            }
> )
> 
> setMethod("myNewRowMeans",
>            signature = "DelayedArray",
>            definition = function(x,...){
>                .myNewRowMeans(x,...)
>            }
> )
> 
> 
> On 4/30/18 9:10 AM, Tim Triche, Jr. wrote:
>> But if you merge methods like that, the error method can be that much 
>> more
>> difficult to identify. It took a couple of weeks to chase that bug down
>> properly, and it ended up down to rowMeans2 vs rowMeans.
>>
>> I suppose the merged/abstracted method allows to centralize any such
>> dispatch into one place and swap out ill-behaved methods once identified,
>> so as long as DelayedArray/DelayedMatrixStats quirks are
>> documented/understood, maybe it is better to create this union class?
>>
>> The Matrix/matrixStats/DelayedMatrix/DelayedMatrixStats situation has 
>> been
>> "interesting" in practical terms, as seemingly simple abstractions appear
>> to require more thought. That was my only point.
>>
>>
>> --t
>>
>> On Mon, Apr 30, 2018 at 11:28 AM, Martin Morgan <
>> martin.morgan at roswellpark.org> wrote:
>>
>>> But that issue will be fixed, so Tim's advice is inappropriate.
>>>
>>>
>>> On 04/30/2018 10:42 AM, Tim Triche, Jr. wrote:
>>>
>>>> Don't do that.  Seriously, just don't.
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Bioconductor_DelayedArray_issues_16&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Rhy4i6H9xaY8HzWv9v_jhOnp5OyEpJcG52RP3nHorU8&s=olbErqY3_l7i45-WeTkaUNGalrQQr-7i59rhJVF6OGQ&e= 
>>>>
>>>>
>>>> --t
>>>>
>>>> On Mon, Apr 30, 2018 at 10:02 AM, Elizabeth Purdom <
>>>> epurdom at stat.berkeley.edu> wrote:
>>>>
>>>> Hello,
>>>>>
>>>>> I am trying to extend my package to handle `HDF5Matrix` class ( or 
>>>>> more
>>>>> generally `DelayedArray`). I currently have S4 functions for `matrix`
>>>>> class. Usually I have a method for `SummarizedExperiment`, which will
>>>>> call
>>>>> call the method on `assay(x)` and I want the method to be able to deal
>>>>> with
>>>>> if `assay(x)` is a `DelayedArray`.
>>>>>
>>>>> Most of my functions, however, do not require separate code 
>>>>> depending on
>>>>> whether `x` is a `matrix` or `DelayedArray`. They are making use of
>>>>> existing functions that will make that choice for me, e.g. rowMeans or
>>>>> subsetting. My goal right now is compatibility, not cleverness, and 
>>>>> I'm
>>>>> not
>>>>> creating HDF5 methods to handle other cases. (If something doesn't
>>>>> currently exist, then I just enclose `x` with `data.matrix` or
>>>>> `as.matrix`
>>>>> and call the matrix into memory — for cleanliness and ease in updating
>>>>> with
>>>>> appropriate methods in future, I could make separate S4 functions for
>>>>> these
>>>>> specific tasks to dispatch, but that's outside of the scope of my
>>>>> question). So for simplicity assume I don't really need to dispatch 
>>>>> *my
>>>>> code* -- that the methods I'm going to use do that.
>>>>>
>>>>> The natural solution for me seem to use `setClassUnion` and I was
>>>>> wondering if such a virtual class already exists? Or is there a better
>>>>> way
>>>>> to handle this?
>>>>>
>>>>> Here's a simple example, using `rowMeans` as my example:
>>>>>
>>>>> ```
>>>>> setGeneric("myNewRowMeans", function(x,...) { standardGeneric("
>>>>> myNewRowMeans")})
>>>>> setClassUnion("matrixOrDelayed",members=c("matrix", "DelayedArray"))
>>>>>
>>>>> #' @importFrom DelayedArray rowMeans
>>>>> setMethod("myNewRowMeans",
>>>>>             signature = "matrixOrDelayed",
>>>>>             definition = function(x,...){
>>>>>                           # a lot of code independent of x
>>>>>                           print("This is a lot of code shared 
>>>>> regardless
>>>>> of
>>>>> class of x\n")
>>>>>                           # a lot of code that depends on x, but is
>>>>> dispatched by the functions called
>>>>>                           out<-rowMeans(x)
>>>>>                           #a lot of code based on output of out
>>>>>                           out<-out+1
>>>>>                           return(out)
>>>>>                   }
>>>>> )
>>>>> ```
>>>>>
>>>>> _______________________________________________
>>>>> Bioc-devel at r-project.org mailing list
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Rhy4i6H9xaY8HzWv9v_jhOnp5OyEpJcG52RP3nHorU8&s=PcBHWXeL0_5KMWSkRgj5UXk640tXb20rGH9sO98oR2w&e= 
>>>>>
>>>>>
>>>>>
>>>>          [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> Bioc-devel at r-project.org mailing list
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Rhy4i6H9xaY8HzWv9v_jhOnp5OyEpJcG52RP3nHorU8&s=PcBHWXeL0_5KMWSkRgj5UXk640tXb20rGH9sO98oR2w&e= 
>>>>
>>>>
>>>>
>>>
>>> This email message may contain legally privileged and/or confidential
>>> information.  If you are not the intended recipient(s), or the 
>>> employee or
>>> agent responsible for the delivery of this message to the intended
>>> recipient(s), you are hereby notified that any disclosure, copying,
>>> distribution, or use of this email message is prohibited.  If you have
>>> received this message in error, please notify the sender immediately by
>>> e-mail and delete this email message from your computer. Thank you.
>>>
>>
>>     [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Rhy4i6H9xaY8HzWv9v_jhOnp5OyEpJcG52RP3nHorU8&s=PcBHWXeL0_5KMWSkRgj5UXk640tXb20rGH9sO98oR2w&e= 
>>
>>
> 
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Rhy4i6H9xaY8HzWv9v_jhOnp5OyEpJcG52RP3nHorU8&s=PcBHWXeL0_5KMWSkRgj5UXk640tXb20rGH9sO98oR2w&e= 
> 

-- 
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