[Bioc-devel] My "==" method breaks existing "==" method for signature c("Rle", "vector')

Hervé Pagès hpages at fhcrc.org
Tue May 27 19:23:46 CEST 2014


Hi Peter,

On 05/26/2014 04:37 PM, Peter Hickey wrote:
> Thanks for the suggested work-around, Martin. In order to define the method on the group generic 'Ops' rather than '==' I will need to generalise .MTuples.compare to the 'Arith', 'Compare' and 'Logic' sub-groups listed in ?Ops, won't I? I'll try to implement the comparison methods for MTuples via the 'Ops' group generic but I want to first make sure that I'm not missing out on getting some of these "for free". The rest of this post might be tangential to the issue I first raised, but it also explains why I implemented '==' rather than on the group generic 'Ops'.
>
> The MTuples class extends GRanges:
>
> setClass('MTuples', representation(extraPos = "matrix"), contains = "GRanges", validity = .valid.MTuples)
>
> I defined .MTuples.compare because while MTuples is based on GRanges, the GRanges 'compare' method is inappropriate for MTuples (see https://github.com/PeteHaitch/cometh/blob/8be01b8b37b6288db5493f53188a193a423ab69f/R/methods-MTuples-class.R if interested). Based on reading ?compare, I'd hoped that the binary "parallel" comparison operators (<=, ==, !=, >=, < and >) would work out-of-the-box. But I already found that I needed to include explicit method definitions for '<=' and '=='  because otherwise these (and the other binary comparison operators) would dispatch on the GRanges methods rather than the MTuples methods. This is because the GRanges '==' and '<=' methods are explicitly implemented as:
>
> setMethod("==", signature(e1="GenomicRanges", e2="GenomicRanges"), function(e1, e2) { .GenomicRanges.compare(e1, e2) == 0L })
> setMethod("<=", signature(e1="GenomicRanges", e2="GenomicRanges"), function(e1, e2) { .GenomicRanges.compare(e1, e2) <= 0L })
>
> I don't understand why these explicit definitions are necessary; the 'compare' method for GRanges is already defined so why don't these work out-of-the-box, which is what I expected based on my reading of ?compare (specifically, point 1 in the Note sub-section).

You're right, they are not needed. I just removed them from
GenomicRanges 1.17.17. See if that helps with the original problem
you reported.

Cheers,
H.


> Because these are explicitly defined, and not simply defined via inheritance, I must also explicitly define '<=' and '==' methods for MTuples (although I do get '>=', '!=', '<' and '>' for free, which is great!). Unfortunately, as you can see, the MTuples '==' method breaks '==' for other signatures. Hope that wasn't too tangential.
>
> Cheers,
> Pete
>
>
> On 27/05/2014, at 2:44 AM, Martin Morgan <mtmorgan at fhcrc.org> wrote:
>
>> On 05/25/2014 09:39 PM, Peter Hickey wrote:
>>> The "==" method that I have defined for my class, MTuples, is breaking the "==" method for signature c("Rle", "vector"). I discovered this when working on something quite unrelated, namely, I couldn't resize IRanges with "fixed = end" when my package was loaded. The attached code highlights the initial problem.
>>>
>>> The error message and traceback were a little hairy - could someone please help me figure out what's going wrong?
>>>
>>
>> I don't have an immediate answer. A work-around is to define the method on the group generic 'Ops' rather than '==', though maybe the generalization of .MTuples.compare to other members of the Ops family is not easy?
>>
>> setMethod("Ops", c("MTuples", "MTuples"), function(e1, e2) TRUE)
>>
>> Martin
>>
>>> Thanks,
>>> Pete
>>>
>>> ------------------------------------------------------------------------------------------------------------------
>>> # Mimics the initial problem
>>> # Fresh R session
>>> library(IRanges)
>>> ir <- IRanges(start = 11, end = rep.int(20, 5))
>>>
>>>   # Works when repeatedly called
>>> resize(ir, 1, 'end') # Works
>>> resize(ir, 1, 'end') # Works
>>>
>>> # The method definition that breaks things
>>> # I haven't included the MTuples class definition or the .MTuples.compare function
>>> # But that shouldn't matter in order to highlight the problem, should it?
>>> setMethod("==", c("MTuples", "MTuples"), function(e1, e2) {
>>>    .MTuples.compare(e1, e2) == 0L
>>> })
>>>
>>> # No longer works
>>> resize(ir, 1, 'end')
>>> ------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> I managed to simplify the reproducible example to the following, but I can't figure out what's going wrong:
>>> ------------------------------------------------------------------------------------------------------------------
>>> # A simplified example
>>> # Fresh R session
>>> library(IRanges)
>>> fix <- Rle('end', 10)
>>>
>>> # Works when repeatedly called
>>> fix == 'end' # Works
>>> fix == 'end' # Works
>>>
>>> # The method definition that breaks things
>>> # I haven't included the MTuples class definition or the .MTuples.compare function
>>> # But that shouldn't matter in order to highlight the problem, should it?
>>> setMethod("==", c("MTuples", "MTuples"), function(e1, e2) {
>>>    .MTuples.compare(e1, e2) == 0L
>>> })
>>>
>>> # Works the first time, but not the second
>>> fix == 'end' # Works
>>> fix == 'end' # Breaks
>>> ------------------------------------------------------------------------------------------------------------------
>>>
>>> The same problem occurs if the vector is numeric and not character, e.g. using 7 instead of 'end'.
>>>
>>> When this breaks I get the error:
>>> ------------------------------------------------------------------------------------------------------------------
>>> Error in Rle(values = callGeneric(runValue(e1)[which1], runValue(e2)[which2]),  :
>>>    error in evaluating the argument 'values' in selecting a method for function 'Rle': Error in as.character(call[[1L]]) :
>>>    cannot coerce type 'builtin' to vector of type 'character'
>>> ------------------------------------------------------------------------------------------------------------------
>>>
>>> My session info is:
>>> ------------------------------------------------------------------------------------------------------------------
>>> R version 3.1.0 (2014-04-10)
>>> Platform: x86_64-apple-darwin10.8.0 (64-bit)
>>>
>>> locale:
>>> [1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
>>>
>>> attached base packages:
>>> [1] parallel  stats     graphics  grDevices utils     datasets  methods
>>> [8] base
>>>
>>> other attached packages:
>>> [1] IRanges_1.22.7      BiocGenerics_0.10.0
>>>
>>> loaded via a namespace (and not attached):
>>> [1] stats4_3.1.0
>>> ------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> --------------------------------
>>> Peter Hickey,
>>> PhD Student/Research Assistant,
>>> Bioinformatics Division,
>>> Walter and Eliza Hall Institute of Medical Research,
>>> 1G Royal Parade, Parkville, Vic 3052, Australia.
>>> Ph: +613 9345 2324
>>>
>>> hickey at wehi.edu.au
>>> http://www.wehi.edu.au
>>>
>>>
>>> ______________________________________________________________________
>>> The information in this email is confidential and intend...{{dropped:8}}
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>> --
>> Computational Biology / Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N.
>> PO Box 19024 Seattle, WA 98109
>>
>> Location: Arnold Building M1 B861
>> Phone: (206) 667-2793
>
> --------------------------------
> Peter Hickey,
> PhD Student/Research Assistant,
> Bioinformatics Division,
> Walter and Eliza Hall Institute of Medical Research,
> 1G Royal Parade, Parkville, Vic 3052, Australia.
> Ph: +613 9345 2324
>
> hickey at wehi.edu.au
> http://www.wehi.edu.au
>
> ______________________________________________________________________
> The information in this email is confidential and inte...{{dropped:21}}



More information about the Bioc-devel mailing list