Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use prepare() for MultisetExpression #222

Open
HighDiceRoller opened this issue Mar 4, 2025 · 1 comment
Open

Use prepare() for MultisetExpression #222

HighDiceRoller opened this issue Mar 4, 2025 · 1 comment
Milestone

Comments

@HighDiceRoller
Copy link
Owner

  • This would help ensure that preparation is done exactly once.
  • This would yield an object for advancing state given incoming counts, and an initial state.
    • Do both have tree structures?
    • An option for None for generators?
  • The former probably gets put in the dungeon (similar to inner_inputs), while the latter more resembles external inputs.
  • What to name the former?
    • MultisetExpressionReady
    • MultisetDelver - riffing off MultisetDungeon
@HighDiceRoller HighDiceRoller added this to the v2.0 milestone Mar 4, 2025
@HighDiceRoller
Copy link
Owner Author

HighDiceRoller commented Mar 10, 2025

Determining pop order is yet again a thicket.

  • We want to resolve input mixtures to definite expressions before we start preparing multiset functions. Actually this may be negotiable since the multiset function only needs to know the variable type.
  • We have to prepare multiset functions so that we can know what detached inputs there are.
  • Should detaching happen before or after expression preparation?
  • We need to know the detached inputs are so that we can know what the preferred pop order is.
  • Initial expression state possibly wants to depend on pop order. Do we do the same prepare() (orderless) - delve.initial_state() (ordered) split as with evaluators?
    • How can we prevent the information needed in delve.initial_state() from unnecessarily affecting the delve's cache key? For evaluators we used the option of externally-provided kwargs.
  • With Transmit multiset cardinality through variables? #227 the preferred pop order and initial expression state may also depend on the upstream expressions. Cardinality can't be determined until after mixtures are resolved. Preferred pop order may depend on the availability of cardinality. So here the sequence would have to be mixtures / detach -> cardinality -> pop order -> initial state.
  • Inner expressions are also currently lacking influence on pop order -- actually, they use eval order. This is interesting; an expression inside a multiset_function looks like any other, so it might be expected to use pop order, though it could also be argued that multiset_function produces an evaluator, which may be expected to use eval order.

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

No branches or pull requests

1 participant