Honestly, I can't think of a good reason for ever considering strand, but
dropping the argument seems undesirable. Given that VRanges extends
GRanges, it should present a super-set of the interface. I'm a little wary
about changing the default, which is kept consisent across all of
GenomicRanges. At the very least, we should probably enforce
ignore.strand=TRUE, but that would be annoying.

The reason VRanges has "+" strand is that the alt/ref nucleotides are
consistent with the "+" strand on the reference. But for overlap
operations, we wish it was "*". Perhaps this means we should enforce "*"
instead of "+" as the strand on VRanges? After all, the strand is
irrelevant, and it's a simple matter of documenting that the alleles are on
the positive strand (as is the convention). The getSeq() functions treat
"*" as "+" already, I think.

Michael

On Fri, Jan 31, 2014 at 12:09 AM, Steve Lianoglou
<lianoglou.steve@gene.com>wrote:

> Comrades,
>
> Forgive my n00briety in these matters, as I've only recently starting
> dealing w/ genomic variants, but since the strand of a VRanges object
> is always constrained to be `+`, does it make sense for the strand of
> a potential non-VRanges 'subject' object (like a GRanges) be
> considered when looking for overlaps between the two?
>
> For instance, assume we load up the VRanges object returned by
> `example(vr)`, which results in to ranges
>
> Then:
>
> R> gr <- as(vr, 'GRanges')
> R> strand(gr) <- c('+', '-')
> R> length(subsetByOverlaps(vr, gr))
> [1] 1
>
> Only the first variant from `vr` is returned, unless we explicitly set
> ignore.strand=TRUE:
>
> R> length(subsetByOverlaps(vr, gr, ignore.strand=TRUE))
> [1] 2
>
> Wouldn't it make more sense for these overlap (and match) methods to
> default to ignore.strand=TRUE when either the query (and maybe even
> the subject) are a VRanges object, even if the other is a GRanges?
>
> Thanks,
> -steve
>
> --
> Steve Lianoglou
> Computational Biologist
> Genentech
>
> _______________________________________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]

