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
Hello, I have a feature request, that is related to some other open issues related to the API of this package.
Currently, there is no API to extract the start and end positions from a PairwiseAlignment. It would be great if the client can easily extract the location of matches (start, end) between the reference and the sequence of the PairwiseAlignment object.
Here is the hack that I wrote to solve this problem for myself, but it would be great if the API could expose an abstraction for locations of matches, or some analogous methods/functions so that the client doesn't have to mess with internal "private" fields.
function GetPairwiseAlignmentSeqStart(aln::PairwiseAlignment)
return aln.a.aln.anchors[1].seqpos + 1
end
function GetPairwiseAlignmentRefStart(aln::PairwiseAlignment)
return aln.a.aln.anchors[1].refpos + 1
end
function GetPairwiseAlignmentSeqEnd(aln::PairwiseAlignment)
return aln.a.aln.anchors[end].seqpos
end
function GetPairwiseAlignmentRefEnd(aln::PairwiseAlignment)
return aln.a.aln.anchors[end].refpos
end
Thanks for your consideration, hope this suggestion is helpful for both users as well as the designers and implementors of this package.
The text was updated successfully, but these errors were encountered:
Hello, I have a feature request, that is related to some other open issues related to the API of this package.
Currently, there is no API to extract the start and end positions from a PairwiseAlignment. It would be great if the client can easily extract the location of matches (start, end) between the reference and the sequence of the PairwiseAlignment object.
Here is the hack that I wrote to solve this problem for myself, but it would be great if the API could expose an abstraction for locations of matches, or some analogous methods/functions so that the client doesn't have to mess with internal "private" fields.
Thanks for your consideration, hope this suggestion is helpful for both users as well as the designers and implementors of this package.
The text was updated successfully, but these errors were encountered: