Skip to content

feat(v1): warn on reordered constants under legacy; spec groupers - #837

Merged
FBumann merged 1 commit into
feat/arithmetic-conventionfrom
fix/v1-reorder-legacy-warn-and-groupers
Jul 16, 2026
Merged

feat(v1): warn on reordered constants under legacy; spec groupers#837
FBumann merged 1 commit into
feat/arithmetic-conventionfrom
fix/v1-reorder-legacy-warn-and-groupers

Conversation

@FBumann

Copy link
Copy Markdown
Collaborator

Note

The following was generated by AI.

Two follow-ups to the §8-exact work (#831/#834), found while auditing open-items.md.

Gap 1 — reordered constants didn't warn under legacy

The "no silent change" guarantee (Stage 1 in open-items.md) requires every v1 behaviour-change to warn under legacy. After #831 made a pure reorder raise under v1, most paths warned — but reordered constant operands slipped through:

reorder caselegacy warned "v1 will raise"? (before)
coeff * x, x + expr (merge)
x + array, x - array, x * array, x / array, expr <= array

The const/broadcast path silently reindexes a reordered constant by label under legacy (via _reindex_reordered_dims), so no mismatch was detected and no warning fired — while v1 raises. This introduced a silent legacy→v1 divergence.

Fix: a warn_reorder flag threaded broadcast_to_coords → _reindex_reordered_dims, set at the 6 arithmetic const/rhs call sites. When legacy conforms a reordered constant it now emits a LinopySemanticsWarning (new _legacy_const_reorder_message, accurately saying legacy reindexes by label — the const path is not positional like merge). The legacy result is unchanged (still reindex-by-label); coeff/merge keep their single existing warning (no double-warn); bounds/mask= (strict=True construction) stay silent, since there coords is the source of truth. Verified: every reorder path warns exactly once under legacy, raises under v1.

Groupers — strict alignment now in the spec

convention.md covered operand alignment (§8) but said nothing about grouper alignment. Added a Groupers paragraph under §13: a groupby grouper aligns to the grouped dimension by §8 — a differing label set or a reorder raises, never positional matching or silent reindex (#827). Also notes multi-key groupers → flat group dim + key aux coords (stacked MultiIndex is legacy-only, §11).

The implementation is #830 (check-and-raise), already on master; it reaches this branch when master merges in. open-items.md now tracks that landing, records the §8-exact decision, and notes the reorder→raise transition-surface additions.

Full suite green; ruff/mypy clean.

Two follow-ups to the §8-exact work (#831/#834), from an open-items.md audit.
Gap 1 — transition-surface hole: after #831 made a pure reorder raise under v1,
reordered *constant* operands (`x + array`, `-`, `*`, `/`, rhs) were still
silently reindexed by label under legacy with no warning, breaking the
"no silent change" guarantee (coeff and merge already warned). Thread a
`warn_reorder` flag broadcast_to_coords -> _reindex_reordered_dims, set at the
arithmetic const/rhs sites; legacy now emits `_legacy_const_reorder_message`
(accurately: reindexed by label, not positional). Legacy result unchanged;
no double-warn; construction (bounds/mask, strict=True) stays silent.
Groupers — add a strict-alignment paragraph to convention.md §13: a groupby
grouper aligns to the grouped dimension by §8 (reorder or set-mismatch raises,
never positional), multi-key -> flat group dim + aux coords. Implementation is
#830 (on master, lands here on merge). open-items.md records the §8-exact
decision and the pending grouper landing.
Full suite green; ruff/mypy clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@FBumann
FBumann merged commit 1b0e1c6 into feat/arithmetic-conventionJul 16, 2026
2 checks passed
@FBumann
FBumann deleted the fix/v1-reorder-legacy-warn-and-groupers branch July 16, 2026 08:57
Sign up for freeto 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

@FBumann