Kristoffer
Kristoffer
Release 0.8.0 is not using WFA but next release will (..if it works at least as well as current method and provides a speedup).
Just an update that this is not yet fixed. It is our top priority and we will be working on it next. Also, this is not an accuracy issue, but...
Although the issue is more a question on evaluation, the discrepancy presented in the issue is most likely fixed in commit 6bbc5b7 due to better placements of repetitive reads. If...
Sounds great. I remember in your dataset there was some(/many?) reads at length 50nt, I don't think strobealign's accuracy will be better than BWA/Bowtie2 for those read lengths for a...
As for true randstrobe hash collisions where the underlying strobemers are different, they will be noticed at the NAM stage. Specifically, when parsing out the leftmost and rightmost position of...
If you mean hash collisions in the actual hash table implementation, I don't know how they are resolved under the hood. For the ransdtrobe hash collisions, here are some example...
After getting more evidence that MAPQ scores are not computed accurately [from this benchmark](https://github.com/ivargr/mapping-benchmarking/blob/benchmarks/reports/main.md) I looked at how I describe the MAPQ score calculation in the paper. It is, in...
Nice idea! I think your solution makes sense. Furthermore, I think it should not obstruct any concurrent and future plans for the indexing. However, I also agree that it has...
To continue the nitpicking. In Algorithm 1, function header, I'm guessing it should be `WF_ALIGN(q,t,p)`, i.e. lowercase `p` where it is the set of penalties. Also, the `WF_NEXT` function call...
First, I like to point out that WFA is a beautiful algorithm. Glad that I finally have some time to learn it in depth. Since this is an influential algorithm,...