fix: predictCoding uses CDS-mapped width for exon/intron boundary deletions (#83)#97
Open
jmg421 wants to merge 3 commits into
Open
fix: predictCoding uses CDS-mapped width for exon/intron boundary deletions (#83)#97jmg421 wants to merge 3 commits into
jmg421 wants to merge 3 commits into
Conversation
Convert \itemize blocks that used \item{label}{desc} syntax to \describe,
and replace empty \item{}{} labels in \describe blocks with the function
signature from the body, resolving all checkRd warnings in isSNV-methods,
PolyPhenDb-class, readVcf-methods, SIFTDb-class, summarizeVariants-methods,
VariantType-class, VCF-class, VcfFile-class, VCFHeader-class, VRanges-class,
and VRangesList-class Rd files.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…etions (Bioconductor#83) A deletion starting in an exon and extending into the intron produced incorrect REFCODON/VARCODON because .getRefCodons() and the frameshift calculation used the genomic width of the variant rather than the transcript-space (CDSLOC) width. For example, a 51bp genomic deletion with only 37bp overlapping the CDS would compute cend using 51, causing the reference codon to extend incorrectly into the next exon's sequence. Fix: replace width(txlocal) (genomic width) with width(mcols(txlocal)$CDSLOC) (CDS-mapped width) in both: - .getRefCodons(): codon boundary calculation - frameshift detection: refwidth for length-change check Fixes Bioconductor#83
jmg421
force-pushed
the
fix/83-exon-intron-boundary-codon
branch
from
July 18, 2026 03:18
1583da3 to
9c8000f
Compare
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
2 participants
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.
Summary
A deletion that starts inside an exon and extends into the adjacent intron produced incorrect
REFCODON/VARCODONvalues because the codon extraction logic used the genomic width of the variant instead of the transcript-space width (CDS overlap only).Example from the issue
predictCodingreported a 54-character REFCODON spanning into the next exon and a 3-character VARCODON extending into intron sequence — both wrong.Root Cause
Two places in
methods-predictCoding.Rusedwidth(txlocal)(the genomic width of the variant) when they should usewidth(mcols(txlocal)$CDSLOC)(the width of the variant as mapped to transcript/CDS coordinates):.getRefCodons()—cendcalculation extends past the actual CDS overlaprefwidthinflated by intronic bases, causing incorrect mod-3 checkFix
Replace
width(txlocal)withwidth(mcols(txlocal)$CDSLOC)in both locations. The CDSLOC IRanges represents the variant's position and extent in transcript coordinates (exons only, introns excluded), which is what the codon arithmetic needs.Fixes #83