Repository navigation
ADD pam_only to the compiled core, so a dropped match never reaches Python - #18
Merged
Merged
Conversation
The Rust scan pushed every hit into a Vec that crosses into Python as a list, so the peak was set at that boundary whatever Python did with it afterwards. It now skips a hit with no PAM, and returns a per-spacer tally of what it found, what ran off a contig end and what had no PAM, so the counters still say what the run saw rather than what it kept. 500 9-mers against chr21: peak 1,056 MB to 538 MB, with the tables byte-identical to the Python-side filter. matches_pam agreed with none of this: its `code` has no value for a genomic N, so it rejected one even at an N of the pattern, where base_matches accepts it by design and the pam_matches column always has. Filtering on the core's own verdict would have dropped rows the table calls TRUE. Both rules now read the same, and the oracle, which had encoded the core's, reads it too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Nov 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #17.
--pam-onlydropped the matches with no PAM, but the Rustscan had already pushed every one of them into a
Vecthat crosses intoPython as a list, so the peak was set at that boundary whatever Python did
afterwards -- on 500 9-mers against chr21, 1,056 MB full and 910 MB filtered.
scan_fastanow takespam_onlyand skips the hit instead of pushing it.It returns, beside the matches, one
(found, off_end, no_pam)per spacer, son_matches,n_off_contig_end,n_no_pam,n_sitesand the per-guide matchcount come from what the scan saw rather than from what it handed back. Python
no longer tallies hits at all, which removes the chance of the two drifting.
500 9-mers against chr21: 1,056 MB to 538 MB, with
guide_genome_annotation.tsvandqc.tsvbyte-identical to the Python-sidefilter.
matches_pamagreed with none of this. Itscodehas no value for agenomic N, so it rejected one even at an N of the pattern -- where
base_matchesaccepts it by design, and thepam_matchescolumn always has.NGG asks nothing of its first position, so an unsequenced base there is still
a PAM; any other code names bases, and an N is not known to be one of them.
Filtering on the core's own verdict would have dropped rows the table calls
TRUE, which is the bug #17 fixed once on the Python side. Both rules now read
the same, and the oracle in
test_core_scan.py, which had encoded the core's,reads it too.
That oracle is the only thing standing behind the scan, so it gained the
tally as well: every run now checks the counts against a naive count of the
naive scan's own hits.
🤖 Generated with Claude Code