Skip to content

X/mR lane order honours an ordered Categorical factor (#144, PR 4) - #152

Merged
cnicholas merged 1 commit into
feat/phased-xmr-phase-statsfrom
fix/ordered-categorical-lane-order
Oct 18, 2026
Merged

cnicholas merged 1 commit into
feat/phased-xmr-phase-statsfrom
fix/ordered-categorical-lane-order

Conversation

@cnicholas

Copy link
Copy Markdown
Owner

Part of #144 (PR 4 of 4). Stacked on #151: the base is feat/phased-xmr-phase-stats, so the diff shows only this change.

Summary

  • What: the canonical row order in DataPreparation.build_keys sorts an ordered pandas Categorical factor by its category codes instead of its labels. Plain string and numeric factors sort exactly as before: the parallel key is built only when an ordered Categorical is present.
  • Why: a stage column with categories before < after already ordered the Xbar/S subgroups that way (the aggregation groups on the factor column), but X/mR lanes, phases and result.strata came out after, before, because the row order compared the raw labels. The staged Xbar/S docs tell analysts to use labels that sort or an ordered Categorical; the second option now holds on every chart.
  • Scope: one sort in build_keys. Residuals that run along the lane-major stream (R2 in ADS 2/3) follow the new order for ordered-Categorical inputs, which is the point: the stream should run in stage order.

Contract / invariants

  • Defaults unchanged for every input without an ordered Categorical factor: the original sort_values(['cell_key', 'obs_id']) line runs untouched; validation/xbar_s_sweep.py identical (0 differing lines); golden masters untouched and passing
  • Residuals unaffected for those inputs; for ordered-Categorical inputs they follow the corrected row order (intended)
  • Row/index alignment preserved — obs_id remains the tie-break within a cell; sort_key is still 0..N-1
  • Output schema compatible
  • Pinned error strings unchanged

Behaviour changes

  • Studies whose factor is an ordered Categorical: X/mR lane order, phase order, lane_boundaries, strata and the row order of the analysis frame follow the category order. CSV inputs are never categorical, so the Bishop gate and every reference run are unaffected.

Methodology

  • No methodology change — ordering only

Tests

  • tests/test_ordered_categorical_lane_order.py (5): ordered before < after gives before, after on phased X lanes, strata, phased Xbar phases, the lane divider and the analysis frame; plain strings still sort after, before; sortable labels need no Categorical; two factors with one ordered sort stage-major then machine; rows within a cell keep source order
  • pytest tests/ — 2638 passed, 7 skipped
  • ruff check .
  • mypy processbehavior — 14 errors, all pre-existing, none in data_preparation.py
  • python validation/e2e_bishop_report.py — 1547 passed, 0 failed, 4 pending; docs/reference/validation.md unchanged

Notes

… factor (#144)

The canonical row order in build_keys sorted the raw factor labels, so a stage
column with categories before < after gave Xbar/S subgroups in that order (the
aggregation groups on the factor column) but X/mR lanes, phases and strata in
the order after, before. The canonical sort now uses an ordered Categorical's
category codes. Every other input sorts exactly as before: the parallel key is
built only when an ordered Categorical is present (xbar_s_sweep: 0 differing
lines; golden masters untouched; gate 1547 / 0 / 4; full suite 2638 passed).
@cnicholas
cnicholas force-pushed the feat/phased-xmr-phase-stats branch from 844abb7 to 3454269 Compare October 18, 2026 22:21
@cnicholas
cnicholas force-pushed the fix/ordered-categorical-lane-order branch from 9b45145 to 398aedd Compare October 18, 2026 22:21
@cnicholas
cnicholas merged commit 7692acc into feat/phased-xmr-phase-stats Oct 18, 2026
17 checks passed
cnicholas added a commit that referenced this pull request Oct 18, 2026
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