Skip to content

Simplify cartesian-product inversion with a peeled row - #730

Open
eb8680 wants to merge 1 commit into
staging-weightedfrom
eb-peel-row-inversion
Open

Simplify cartesian-product inversion with a peeled row#730
eb8680 wants to merge 1 commit into
staging-weightedfrom
eb-peel-row-inversion

Conversation

@eb8680

@eb8680 eb8680 commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Rewrites the cartesian-product inversion rule ReduceDistributeCartesianProduct in effectful/ops/monoid.py. No behaviour change is intended.

What changed

Peeling replaces the per-summand substitution closure. _PeelRow is a Mapping that stands in for the row variable during one evaluate pass. Because it occupies the mapping position of every row[..], a subscript is recognised by what it is indexing rather than by comparing the mapping against the variable it came from. _peel_subscript routes _MappingTerm.__getitem__ back to it (row indices are symbolic, so _MappingTerm.__getitem__ would never hand a mapping a symbolic key on its own). Each subscript returns the narrowed row and records the plate variable used at the peeled position; row[p] with nothing left over returns the row's own value.

This replaces row_substitute plus its InvalidIndexError control flow: one pass peels every summand, and the per-summand checks that remain are just "the plate this summand's bundle binds is one of the plates the row was indexed by, and its range matches". _CannotPeel carries the give-up signal, as InvalidIndexError did.

_PeelRow also counts uses against peels per plate, so survives() can tell whether a plate is still referred to after peeling; only surviving plates need renaming onto the shared plate variable. The peeled row is bound to a fresh peeled_var = defop(stream_key) rather than reusing stream_key, since the row it names is a narrower one.

The trailing _to_body special case is gone: in the fully-peeled case the peeled row has already answered every subscript with the row's value, so monoid.reduce(combined, union_streams) is the same expression the old handler({_MappingTerm.__getitem__: _to_body})(evaluate)(combined) produced.

CartesianProductNormalizeIntp is removed. Factor may have moved product factors into nested reductions of the same monoid, hiding the product this rule looks for. Previously the whole candidate was rebuilt under a dedicated CartesianProductNormalizeIntp so that ReduceUnfactor could merge the stream bundles. That is now done inline over the body's own top-level factors: the shape being looked for is a product of factors, so only the top level matters. The nested streams are absorbed into streams when they do not collide, which is exactly what ReduceUnfactor would have done.

grep -rn CartesianProductNormalizeIntp over the repo (excluding .git) matched only its definition and its single use inside monoid.py — nothing in effectful/handlers/jax/monoid.py, tests/, or docs/ referred to it. Its removal also drops the now-unused from effectful.internals.runtime import interpreter import; defop is now imported from effectful.ops.syntax.

Testing

No new tests: tests/test_ops_monoid.py and tests/test_handlers_jax_monoid.py already cover this rule (530 tests, all passing). A full tests/ sweep excluding tests/test_handlers_llm_*.py gives 18317 passed, 2 skipped, 2078 xfailed, 0 failed, matching staging-weighted.

mypy, ruff check and ruff format are clean apart from the pre-existing effectful/handlers/jax/monoid.py:382 error, which is also present on staging-weighted.

Note for review

Six typing.cast(...) calls in the new code are not in #724 — they are runtime no-ops added purely to keep mypy clean, since Term.args elements type as Expr. They are the only difference between this rule's body here and the one in #724, which is otherwise verbatim.

Split out of #724 for review. Independent of the sibling
ReduceGroundCartesianProduct PR, also split out of #724.

🤖 Generated with Claude Code

@eb8680
eb8680 marked this pull request as ready for review July 28, 2026 16:11
@eb8680
eb8680 requested a review from jfeser July 28, 2026 16:11
Comment thread effectful/ops/monoid.py
PlusEmpty(),
PlusSingle(),
PlusAssoc(),
ReduceUnfactor(),

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.

Can ReduceUnfactor be removed in this PR?

Comment thread effectful/ops/monoid.py
Comment on lines +846 to +850
def __iter__(self):
return iter(())

def __len__(self) -> int:
return 0

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.

These should raise, I think. I assume they're unused.

Comment thread effectful/ops/monoid.py
# what ``ReduceUnfactor`` does, applied here to the body's own factors
# rather than by renormalizing the whole candidate: the shape being
# looked for is a product of factors, so only the top level matters.
if isinstance(body, Term) and _is_monoid_plus(body.op):

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.

This shouldn't apply to any Monoid.plus.

Comment thread effectful/ops/monoid.py
# Absorbing their streams back into this one exposes it again. This is
# what ``ReduceUnfactor`` does, applied here to the body's own factors
# rather than by renormalizing the whole candidate: the shape being
# looked for is a product of factors, so only the top level matters.

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.

I'm not convinced that doing one step of unfactoring is sufficient. What prevents a stream from being moved more deeply into the term?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I can just reinstate the previous unfactoring behavior, I think this part is orthogonal to the other changes in the PR.

@jfeser
jfeser force-pushed the staging-weighted branch from 0553c4a to fe1e760 Compare July 30, 2026 17:05
Standing a `_PeelRow` in for the row variable puts it in the mapping
position of every `row[..]`, so a subscript is recognised by what it is
indexing rather than by comparing against the variable it came from. One
evaluation pass peels every summand and records the plate each folds over,
replacing the per-summand `row_substitute` closure and its
`InvalidIndexError` control flow.

Nested same-monoid reductions are absorbed inline at the top level rather
than by renormalizing the whole candidate under a dedicated
interpretation, so `CartesianProductNormalizeIntp` is no longer needed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jfeser
jfeser force-pushed the eb-peel-row-inversion branch from c62a3cb to a0306a8 Compare July 30, 2026 17:59
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