[Bioc-devel] coverage,GenomicRanges interpretation of 'weight'

[Hervé Pagès]

On 02/24/2012 12:30 AM, Nicolas Delhomme wrote:
> Hi Hervé,
>
> Although I agree that the change makes sense (and how!), quite some of my own functions use the RangedData "old" width interface and these pieces of code have been distributed around. Therefore, when you change it, could you do so in a backward compatible fashion? I.e. that it still accepts a list but convert it internally to a vector while emitting a "deprecation" warning for example? That'd be awesome :-)

Sure, we'll do that. Thanks for the feedback!

H.

>
> Cheers,
>
> Nico
>
> ---------------------------------------------------------------
> Nicolas Delhomme
>
> Genome Biology Computational Support
>
> European Molecular Biology Laboratory
>
> Tel: +49 6221 387 8310
> Email: nicolas.delhomme at embl.de
> Meyerhofstrasse 1 - Postfach 10.2209
> 69102 Heidelberg, Germany
> ---------------------------------------------------------------
>
>
>
>
>
> On 23 Feb 2012, at 23:45, Hervé Pagès wrote:
>
>> On 02/23/2012 11:22 AM, Cook, Malcolm wrote:
>>> Another way the interface to coverage could/should agree between GenomicRanges and RangedData is the expectation of how width is encoded.
>>>
>>> For GenomicRanges   "'width' must be NULL or a numeric vector"
>>> For RangedData, "  'width' must be a non-empty list"
>>>
>>> Of course not crucial.  But, the disagreement is easy to trip over.
>>
>> In the early days, the "coverage" method for GenomicRanges also used
>> to take a non-empty list but I changed this about one year ago for
>> the "NULL or a numeric vector" interface, which I find more natural
>> (putting the widths for each seqlevel in a numeric vector is
>> more natural than putting them in a list where each element is a
>> numeric vector of length 1, and it's consistent with 'seqlengths(x)').
>>
>> We should definitely make the same change to the other "coverage"
>> methods that still use the old interface though (RangesList,
>> RangedData, there might be more...). I've put this on our list.
>>
>> Thanks,
>> H.
>>
>>>
>>> ~Malcolm
>>>
>>>
>>>> -----Original Message-----
>>>> From: bioc-devel-bounces at r-project.org [mailto:bioc-devel-bounces at r-
>>>> project.org] On Behalf Of Cook, Malcolm
>>>> Sent: Thursday, February 23, 2012 1:14 PM
>>>> To: 'bioc-devel at r-project.org'
>>>> Subject: [Bioc-devel] coverage,GenomicRanges interpretation of 'weight'
>>>>
>>>> It would be great I think if coverage,GenomicRanges  interpetation of
>>>> 'weight' would be similar to that for RangedData
>>>>
>>>> 	For 'RangedData' objects, this can also be a single string naming a
>>>> column to be used as the weights.
>>>>
>>>> In the case for coverage,GenomicRanges  we would want to weigh by any
>>>> attribute (i.e. score) in the values DataTable.
>>>>
>>>> is this reasonable?
>>>>
>>>> I like being able to refer symbolically as provided by RangedData.  It allows
>>>> me to write, for instance, this utility function:
>>>>
>>>> coverageByStrand<-function(x,...){
>>>>    ## PURPOSE: compute the coverage of x, split by 'strand'.
>>>>    ## RETURNS: a list of SimpleRLEList (by chromosome)
>>>>    res<-lapply(split(x,strand(x)),coverage,...)
>>>> }
>>>>
>>>> which I can then use as
>>>>
>>>> someStrandedCoverage<-
>>>> coverageByStrand(someStrandedFeaturesAsGenomicRanges,weight='theDa
>>>> taTableAttributeHoldingSomeWeightFactor')
>>>>
>>>> Otherwise I would have to test for the presence of a weight attribute and
>>>> split it by strand, and use mapply instead, etc....
>>>>
>>>> Regardless of the merits, having the interface to coverage be similar
>>>> between RangedData and GenomicRanges is arguably desirable.
>>>>
>>>> My workaround is to convert to RangedData for the computation.  Definitely
>>>> not urgent.
>>>>
>>>> Malcolm Cook
>>>>
>>>> _______________________________________________
>>>> Bioc-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>> _______________________________________________
>>> 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 fhcrc.org
>> Phone:  (206) 667-5791
>> Fax:    (206) 667-1319
>>
>> _______________________________________________
>> 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 fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319