[Bioc-devel] Extending GenomicRanges::`intra-range-methods`
Ad|ty@@Bh@gw@t @end|ng |rom mp|-bn@mpg@de
Mon Sep 16 10:30:06 CEST 2019
Hmm no that wouldn't work, it would become messy trying to figure out when incompatible arguments are provided.
From: Bioc-devel [bioc-devel-bounces using r-project.org] on behalf of Bhagwat, Aditya [Aditya.Bhagwat using mpi-bn.mpg.de]
Sent: Monday, September 16, 2019 10:09 AM
To: Michael Lawrence
Cc: bioc-devel using r-project.org
Subject: Re: [Bioc-devel] Extending GenomicRanges::`intra-range-methods`
Thank you for the pointer to plyranges - looks very useful!
> Maybe a better name is "straddle" for when ranges
> straddle one of the endpoints? In keeping with the current pattern of
> Ranges API, there would be a single function: straddle(x, side, left,
> right, ignore.strand=FALSE). So straddle(x, "start", -100, 10) would
> be like promoters(x, 100, 10) for a positive or "*" strand range.
Cool suggestion, and a really fitting verb :-)
Just slightly modifying your suggestion makes the API fully generic (waaw!), generalizing over left_flank, right_flank, as well as slop:
straddle(leftstart, leftend, rightstart, rightend)
Would it be worth having such functionality in GenomicRanges or plyranges, rather than multicrispr<https://gitlab.gwdg.de/loosolab/software/multicrispr>?
> That brings up strandedness, which needs to be considered here. For
> unstranded ranges, it may be that direct start() and end()
> manipulation is actually more transparent than a special verb.
I ended up using left/right for unstranded, and up/down for stranded operations.
> The functions that involve reduce() wouldn't fit into the intrarange
> operations, as they are summarizing ranges, not transforming them.
> They may be going too far.
True. Actually, the functions would be cleaner without the reduce(), I think I'll take that out.
[[alternative HTML version deleted]]
Bioc-devel using r-project.org mailing list
More information about the Bioc-devel