Skip to content

Carry the measured gene, the element's location, and the channel - #16

Merged
emattei merged 2 commits into
mainfrom
feat/element-mapping-genes
Oct 15, 2026
Merged

emattei merged 2 commits into
mainfrom
feat/element-mapping-genes

Conversation

@emattei

@emattei emattei commented Oct 15, 2026

Copy link
Copy Markdown
Collaborator

Three gaps, each found by reading the assembled MuData and asking where
something had gone.

The measured gene, in the element mapping

guide_element_mapping.tsv named no gene, so the mapping could not stand on
its own. It now takes the same --genes pairs table igvf-export does,
through the same _measured_genes lookup, so the two tables cannot disagree
about which gene an element was measured against.

promoter        3,380 / 3,890
e2g_validated     180 / 379
peak                0 / 44,501

element_location

genomic_element cannot say whether an element sits in a gene: promoter and
enhancer win on precedence before the gene body is ever tested. The cross-tab
is the argument for a separate column.

                 genic   intergenic
distal element       0       14,900
exon             2,995            0
intron          14,631            0
promoter         8,348          499     <- split
enhancer           230          110     <- split

Computed from the same in_gene overlap igvf_export already had, so no new
input and no second source of truth.

What the channel is

The object said nothing about which channel it held. --channel NAME=VALUE,
repeatable, joins every cell's obs and is kept in uns['channel'], so
replicate, day, chip and batch travel with the counts.

Stated rather than parsed. The names live in FASTQ paths, and reading them
there would tie the tool to one lab's naming scheme.

730 tests pass.

🤖 Generated with Claude Code

emattei and others added 2 commits October 15, 2026 12:02
Three gaps, each found by reading the assembled object and asking where
something had gone.

`guide_element_mapping.tsv` named no gene, so the mapping could not stand on
its own. It now takes the same --genes pairs table igvf-export does, through
the same lookup, so the two cannot disagree: 3,380 of 3,890 promoter rows and
180 of 379 e2g_validated rows gain one.

`genomic_element` cannot say whether an element sits in a gene, because
promoter and enhancer win on precedence before the gene body is tested. The
cross-tab shows why that matters: exon, intron and distal are determined, but
499 promoter and 110 enhancer guides sit outside any gene. `element_location`
is computed from the overlap igvf-export already had, so no new input and no
second source of truth.

And the object said nothing about which channel it was. --channel NAME=VALUE
joins every cell's obs and is kept in uns, so replicate, day, chip and batch
travel with the counts. Stated rather than parsed: the names live in FASTQ
paths, and reading them there would tie the tool to one lab's scheme.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Each addition is something a user has to be told, not inferred: --genes on
element-mapping, --channel on mudata-builder, and why element_location
exists when genomic_element already names a class.

The last carries the cross-tab, because the argument for the column is the
499 promoter and 110 enhancer guides that sit outside any gene while every
exon and intron guide is inside one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@emattei
emattei merged commit 029976d into main Oct 15, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant