Skip to content

Generalize ReduceEqualityMaskRange - #742

Open
jfeser wants to merge 15 commits into
staging-weightedfrom
jf-weighted-eq-elim
Open

Generalize ReduceEqualityMaskRange#742
jfeser wants to merge 15 commits into
staging-weightedfrom
jf-weighted-eq-elim

Conversation

@jfeser

@jfeser jfeser commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@jfeser
jfeser marked this pull request as ready for review August 3, 2026 19:51
Comment thread effectful/ops/monoid.py
@jfeser
jfeser marked this pull request as draft August 4, 2026 00:59
@jfeser
jfeser changed the base branch from staging-weighted to jf-monoid-inverse August 7, 2026 20:01
@jfeser
jfeser force-pushed the jf-weighted-eq-elim branch 2 times, most recently from 3d226e0 to 2e446b5 Compare August 11, 2026 16:05
@jfeser
jfeser marked this pull request as ready for review August 11, 2026 16:05
@jfeser
jfeser force-pushed the jf-weighted-eq-elim branch 2 times, most recently from 0e4c9a7 to b4593f8 Compare August 11, 2026 17:11
Base automatically changed from jf-monoid-inverse to staging-weighted August 12, 2026 14:53
@eb8680
eb8680 force-pushed the jf-weighted-eq-elim branch from 2f1488b to 7a3a018 Compare August 12, 2026 14:53
Comment thread effectful/ops/monoid.py
for solution in _solve_stream_equality(cond, streams)
if cls._can_restrict(streams[solution.stream_op])
]
ranked_conds = sorted(matched_conds, key=lambda c: (*cls._rhs_cost(c[2]), c[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.

What is being added by this new cost-based sorting step here? If it's important, is there a way to achieve the same thing through choose_contraction, so there's only a single source of cost-based non-determinism? If it's not important, can we just retain the original order in matched_conds and remove it?

return {apply: _apply}


def sizeof(term: Expr) -> int:

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 only see one place in ops.monoid that uses sizeof. If this can't be removed, do you expect it to be used anywhere else in the future? It seems like a very questionable basis for a cost model.

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.

This code is still in flux, so I'm not sure. In the robotl use case, effectful overhead is the main cost (both before and after the caching work). A cost model that reduces term growth is essential. I'd expect future rewriting rules to have similar problems with creating huge terms, so I expect sizeof to remain useful.

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