Skip to content

UPDATE the gotchas with the PAM N rule and where it lives #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
emattei merged 1 commit into from
Nov 9, 2026
Merged

UPDATE the gotchas with the PAM N rule and where it lives #19

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions CLAUDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -329,6 +329,13 @@ and narrowing it would buy nothing.
`+`, `start + 3` on `-`). The IGVF-named columns keep these
definitions, which differ from the lab's DC_TAP tables (the guide page
has the comparison);
- **`N` in a PAM pattern is satisfied by a genomic `N`.** `NGG` asks
nothing of its first position, so an unsequenced base there is still a
PAM; every other code names bases, and an `N` is not known to be one of
them. The rule lives in `base_matches` and in the Rust `matches_pam`,
which disagreed with it until they were reconciled, and in the oracle
of `tests/test_core_scan.py`, which had encoded the Rust reading.
Change one and the other two are wrong;
- classes count sites whose genomic PAM matches. A site whose PAM does
not stays in the table with `pam_matches` `FALSE` and counts nowhere,
so a spacer matching twice with one PAM is `unique`. `--pam-only`
Expand Down
Loading