Repository navigation
v0.4.0
Breaking behavior change. The public API is unchanged — cargo semver-checks reports no
semver update required — but find_mems returns materially different results, so this takes
a minor bump under the pre-1.0 policy above rather than the patch bump an API-only check
would allow.
Fixed
-
Breaking.
BidirFmIndex::find_memsnow enumerates MEMs in the MUMmer / BWA sense:
a query interval is reported when at least one of its occurrences is maximal in both
directions at that occurrence. It previously required every occurrence to be
maximal, so a single extendable occurrence in any one reference deleted the interval.
Both the right-maximality test (the forward loop stopped only when the occurrence set went
empty, discarding occurrences that dropped out mid-extension) and the left-maximality test
(rejecting the interval if any occurrence was left-extendable) were affected.Consequences of the old behavior: at most one interval per query start position, and a
result set that collapsed ontofind_smems, making MEM-vs-SMEM comparisons through this
API a guaranteed null result. In a database of near-identical references, per-reference
match recovery was systematically sparse.For
query = ACGTACGTACagainstACGTACGTACandACGTACTwithmin_len = 2, the result
goes from{(0,10)}to{(0,2), (0,6), (0,10), (4,10), (8,10)}.find_smemsis unaffected and unchanged: the containment-maximal MEMs under the new
definition are exactly the SMEMs it already returned.
Changed
- Breaking.
Mem::match_countandMem::positionsfromfind_memsnow cover only the
maximal occurrences of a match, not every occurrence of the matched substring. find_memsoutput size is now bounded by O(|query|²) rather than |query|;min_lenis the
only guard. Expectbenches/mem_bench.rsandbenches/mem_positions_bench.rstimings to
move accordingly.
Known issues
find_mems_gpustill runs the previous whole-set algorithm and is not equivalent to
find_mems. Theshaders/mem_find.wgslMODE_MEM port is tracked inKNOWN-ISSUES.md.