On Tue, Feb 11, 2014 at 6:58 PM, Hervé Pagès 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
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 vecto
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 <
kasperdanielhan...@gmail.com> wrote:
> Sounds reasonable, _especially_ if you think it is faster. You're the
> expert. I assume you will allow the user
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 wrote:
> Just a thought: support coverage
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]]
__
