Skip to content

[3/5] Refactor: extract the charged fragment type annotation and the pointer reannotation - #436

Open
GeorgWa wants to merge 1 commit into
refactor/private-fragment-parsing-helpersfrom
refactor/annotate-charged-frag-types
Open

[3/5] Refactor: extract the charged fragment type annotation and the pointer reannotation#436
GeorgWa wants to merge 1 commit into
refactor/private-fragment-parsing-helpersfrom
refactor/annotate-charged-frag-types

Conversation

@GeorgWa

@GeorgWa GeorgWa commented Aug 31, 2026

Copy link
Copy Markdown
Collaborator

Pure refactor. No functional change, output bit-identical to main.

Move two concerns out of the body of flatten_fragments, so the memory changes that follow are diffs in named helpers instead of a long function body.

  • Return the series id, loss id, charge and direction as typed arrays instead of four parallel lists of Python ints. Tiling a typed array keeps its dtype, so the dense type/loss_type/charge/direction arrays no longer pass through an int64 intermediate of 8 bytes per dense slot.

Stacked on #435. Splitting #429.

🤖 Generated with Claude Code

…tion

Move two concerns out of the body of `flatten_fragments`: the per-column
annotation of the charged fragment types, and the reannotation of the precursor
pointers. The function now reads as its steps, and the memory refactoring that
follows changes a named helper instead of a long function body.

`_annotate_charged_frag_types` returns typed arrays rather than four parallel
lists of Python ints. Tiling a typed array keeps its dtype, so the dense
type/loss_type/charge/direction arrays no longer pass through an int64
intermediate of 8 bytes per dense slot.

No functional change. Output stays bit-identical to main across 5400 generated
configurations of library shape, padding, top-k, intensity threshold and
custom_columns.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@GeorgWa GeorgWa changed the title Refactor: extract the charged fragment type annotation and the pointer reannotation [3/5] Refactor: extract the charged fragment type annotation and the pointer reannotation Aug 31, 2026
fragment_mz_df.columns.values
)

# tiling the typed arrays keeps their dtype. A tiled list of Python ints gave

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"tiling the typed arrays keeps their dtype" -> I feel this is redundant? like "a = 1+1 # this will stay an int" ? also, second part of comment references previous implementation.

(I am not saying the information is not valuable, it's just that code is not the right place for it .. this would be a good example of the PR author commenting his own code to guide the review)

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.

2 participants