You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Locus object's distance_to_locus attribute calculates the distance between the loci on opposite strands, as inf.
Demo code:
from pyensembl.locus import Locus
## loci
locus1=Locus(contig="1", start=1, end=2,strand='+')
locus2=Locus(contig="1", start=4, end=5,strand='-')
## distance
print(locus1.distance_to_locus(locus2))
## change the strands to be the same
locus2.strand='+'
## distance
print(locus1.distance_to_locus(locus2))
### output
# inf
# 2
Because unifying the strands gives the correct distance, I wonder if this is a bug, or if it is supposed to be a feature for e.g. maybe to discourage calculating distances between loci on opposite strands.
The text was updated successfully, but these errors were encountered:
This was intentional since "distance" on opposite strands wasn't useful for my usecases when I started working on PyEnsembl. Since making it strand-invariant changes the semantics, would you be OK with a different helper function?
I'm not sure what to call it distance_to_locus_on_either_strand, strand_invariant_distance_to_locus, ... ?
As for the name of the new helper function, to make it easy to find, I would personally like if it would have the distance_to_locus prefix, as in distance_to_locus_on_either_strand. That way, this variant function could be easily found once one knows the name of the original function.
Adding a new helper function would do it. But how about adding a parameter, called ignore_strands for example, to the existing function instead? Could that be easier/simpler? Asking because when I came across this issue, intuitively, the first thing I did was to look for the parameter that could allow me to calculate the distance in a strand-invariant way.
Locus
object'sdistance_to_locus
attribute calculates the distance between the loci on opposite strands, as inf.Demo code:
Because unifying the strands gives the correct distance, I wonder if this is a bug, or if it is supposed to be a feature for e.g. maybe to discourage calculating distances between loci on opposite strands.
The text was updated successfully, but these errors were encountered: