Closed kewiechecki closed 2 years ago
Hi,
According to ?GenomicRanges::intersect
the strict.strand
argument is supported by the pintersect()
method for GRanges objects, not by the intersect()
method.
Note that vector-wise set operations union()
, intersect()
, and setdiff()
treat the strand strictly in the sense that +
, -
, *
are considered to be 3 separate spaces. This means that ranges on +
or -
are not considered to intersect with ranges on *
. This is consistent with reduce()
which they use internally to turn the supplied GRanges objects x
and y
into "sets" of genomic positions (i.e. x
and y
are conceptually replaced with reduce(x)
and reduce(y)
before computing their union, intersection, or setdiff).
It would probably make sense to control this by adding the strict.strand
argument to these methods. Feel free to submit a PR if you'd like to give this a shot.
In the meantime, a somewhat hacky solution is to "split" the ranges in y
that are on *
, that is, to replace each of them with 2 ranges, one on +
and one on -
. This would only be guaranteed to do the right thing if x
doesn't also have ranges on *
, I think.
Cheers, H.
When I attempt to find the intersect of a set of stranded ranges and a set of unstranded ranges, ranges with strand
"*"
do not match ranges with strand"+"
or"-"
.gives the unexpected output
When
ignore.strand=T
, it gives the expected output.This appears to be an issue with
strict.strand
defaulting toTRUE
rather thanFALSE
(as indicated in the documentation forGenomicRanges::intersect
), but when I attempt to unset it, the argument isn't recognized.