On Tue, Feb 11, 2014 at 6:58 PM, Hervé Pagès <hpages@fhcrc.org> wrote:

> Hi,
>
> Why not. But I don't expect a significant speed up. Here is why:
>
> There are actually 2 algos implemented by coverage(): one called "sort"
> that computes the coverage directly into "Rle space", and one called
> "hash" that computes the coverage into an ordinary integer vector and
> turns this vector into an Rle at the end (this conversion is cheap).
>
> By default coverage() tries to automatically pick up the appropriate
> algo: "hash" when the data are dense, "sort" otherwise. The criteria
> used to decide whether the data are dense or not is a little bit
> naive (and could maybe be improved?): it just compares the number
> of ranges in the input with the length of the coverage vector to
> return. If nb of ranges > 0.25 * length-of-coverage-vector, the data
> is considered to be dense. Clearly this formula is kind of arbitrary
> and I'm sure it could be tweaked a little bit to do a better job.
>
> Note that the user can choose the algo to use via the 'method' arg.
> If you know your data are dense, use method="hash". It will be almost
> as fast as if coverage() was returning an IntegerList, except that
> the coverage is turned into an Rle (but only at the end). I would
> expect this final coercion to be nothing compared to the computation
> of the coverage itself. This would need to be confirmed by some
> profiling though.
>
> Anyway maybe there are other benefits of returning an IntegerList:
> smaller memory footprint when the data are dense,
> more beginner-friendly container, maybe slightly faster
> downstream computations (can this be a bottleneck?), others?
>
>
Thanks for the explanation. The things you mention above are largely what
motivated the suggestion. When dealing with e.g. WGS data, the Rles become
cumbersome.


> H.
>
>
>
> On 02/11/2014 05:06 PM, Michael Lawrence wrote:
>
>> Right, it would be a choice. The compression is not worth it when the data
>> are dense.
>>
>>
>> On Tue, Feb 11, 2014 at 4:18 PM, Kasper Daniel Hansen <
>> kasperdanielhansen@gmail.com> wrote:
>>
>>  Sounds reasonable, _especially_ if you think it is faster.  You're the
>>> expert.  I assume you will allow the user to choose the return value?
>>>   Having the option of Rle's is still nice, for some use cases.
>>>
>>>
>>> On Tue, Feb 11, 2014 at 7:12 PM, Michael Lawrence <
>>> lawrence.michael@gene.com> wrote:
>>>
>>>  Just a thought: support coverage calculation directly to IntegerList.
>>>> Will
>>>> very often be faster than RleList, especially when limiting to regions
>>>> without long runs of zeros, and with WGS data.
>>>>
>>>> Something to put on the TODO list?
>>>>
>>>> Michael
>>>>
>>>>          [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> Bioc-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>>
>>>
>>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> 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: hpages@fhcrc.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
>

	[[alternative HTML version deleted]]

