Marcel Martin

To answer a couple of questions: > I guess you verified it also had intended behaviour in the bug reported. Current strobealign reports `143=7S` for the alignment in the bug...

The potential is ... limited: variant | runtime (s) | |-|-| no hash | 19.20 | fxhash | 19.30 | xxh64 | 19.30 | xxh3 | 19.30 | wyhash |...

To clarify: The test above includes the full strobealign run, so the numbers could be a bit biased if anything done after the hashing also changes (I should have used...

Here are accuracy measurements for a couple of datasets. (Dmel is *Drosophila melanogaster*) hash function|Dmel 2x50| Dmel 2x100|Dmel 2x300|CHM13 2x50|CHM13 2x100|CHM13 2x200|CHM13 2x300|rye 2x150| -|-|-|-|-|-|-|-|-| no hash |90.081 | 92.377...

Since I still have the log files, this took only a couple of minutes. These are the "Total distinct strobemers" numbers from the logs (did you mean this?). hash function|Dmel...

Since I discovered `XXH_INLINE_ALL` (PR #302), I wanted to see whether it can mitigate some of the lost speed when using `XXH64` on the s-mer. This seems to be the...

Thanks, good point!

Hi, I’m probably missing some context since this recodonization is also new to me, but can you clarify what your question is? It seems that strobealign doesn’t give you coverage...

Hm, I guess the answer may be that [`std::inplace_merge` uses extra memory](https://stackoverflow.com/questions/11367674/inplace-merge-what-causes-a-complexity-of-nlogn-vs-n-1).

Ah, [C++ inplace is not actually "in place"](https://stackoverflow.com/questions/4373307/is-it-possible-to-do-an-inplace-merge-without-temporary-storage/4375732#comment4762870_4373307) (as I would have understood it).