The order of results is not important for the analysis. I have updated the test
case with a new expected result.
--
Dario Strbenac
PhD Student
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-projec
Hi Michael,
On 01/15/2015 11:59 AM, Michael Lawrence wrote:
My concern is mostly in user code not seen in Bioc svn.
I understand but the fate of that code is to get out of sync
sooner or later. And sooner rather than later if it relies on
undocumented behavior.
But perhaps the
partial sortin
My concern is mostly in user code not seen in Bioc svn. But perhaps the
partial sorting (by query) is sufficient for many of those.
On Thu, Jan 15, 2015 at 11:34 AM, Hervé Pagès wrote:
> Hi guys,
>
> Indeed, the Hits object returned by findOverlaps() is not fully
> sorted anymore. Now it's sorte
Hi guys,
Indeed, the Hits object returned by findOverlaps() is not fully
sorted anymore. Now it's sorted by query hit *only* and not by query
hit *and* subject hit. Fully sorting a big Hits object has a high
cost, both in terms of time and memory footprint. The partial
sorting is *much* cheaper:
If it's not documented, it should be, because Patrick did it on purpose
(the output from the IntervalTree code is not sorted). We could add an
argument to disable the sorting for when the extra speed is desired. But it
has proven useful.
On Thu, Jan 15, 2015 at 6:42 AM, Kasper Daniel Hansen <
kasp
Has it ever been documented that the return object is sorted in a specific
way? I just want to make sure we think about whether that is something we
want to enforce giving the possibility of using a different algorithm in
the future.
We could also address this by implementing (perhaps it already
I bet there is a lot of code that depends on having the hits (conveniently)
ordered by query,subject index, so we should try to restore the previous
behavior.
On Wed, Jan 14, 2015 at 8:00 PM, Dario Strbenac
wrote:
> Hello,
>
> For an identical query, the matrix results are in a different order.
Hello,
For an identical query, the matrix results are in a different order. Consider
the subject hits of the last two rows :
> mapping# R Under development (unstable) (2015-01-13 r67453) and
> IRanges 2.1.35
queryHits subjectHits
[1,] 1 1
[2,] 1
