Possible expression overhaul?

[HighDiceRoller]

• Is there a simpler way to do this?
• You can't do evaluator(x) within a multiset_function, you have to do x.evaluate(evaluator=evaluator).
  • This was just a bug.
• It would be nice to be able to append Die operations to the end. This would seem to require either using __getattr__, which is potentially dangerous, or adding expression versions for all Die methods, which is quite tedious.

On second thought, you wouldn't do fn + 1 to add 1 to the result of a function, you'd wrap the function. This also helps emphasize the die-pool distinction.

• Multiple generators, especially multiple deals, are computationally expensive. Is it worth adding some way to cycle through one input at a time?

Would this even actually be faster? Suppose we had a null evaluator and fed it two pools of size $n$. Then the number of generator states would still go as $n^2$. Each of them has to evaluate $O(n)$ possible next generator states, so maybe there is a win here not going to $O(n^2)$ next states? Though this doesn't keep it from being exponential in the number of generators.

• I'm not sure feeding fully-bound but non-generator expressions to evaluate() works correctly right now.

The existing direction is to have a temporary ExpressionEvaluator gobble up everything except the generators. The cache is therefore lost after evaluation, though if we instead had the generator side of the expression remain intact, it's unclear how reusable that cached generator would be.

[HighDiceRoller]

More issues came up in #78. Supposing we are doing a pool reroll and we want to prioritize lower dice for the reroll, we would split the pool into three parts:

• Dice not eligible for rerolls.
• Dice rerolled.
• Dice eligible for rerolls, but were not chosen for reroll. Since we took the lowest to be rerolled, this would be the highest of the dice eligible for rerolls.

Unfortunately, while the first two can be combined into a single Pool as it stands, the last cannot, since the "highest" selection is only executed over some of the dice.

General mixed expressions?

This would require considerable changes since expressions can't currently introduce extra probability. It is also likely overkill since I don't currently have any anticipated use-cases where the user would manually construct a mixed expression.

Pool additive unions?

This would entail having the + operator on pools create a generator rather than an expression. This generator would still have to be able to combined under what is currently PoolMixture.

Should this be a separate class, or integrated under Pool itself?

Should Deals be able to get in on this as well?

Can/should we use this to take advantage of known multiset sizes?

[HighDiceRoller]

Possible class hierarchy:

• MultisetExpression
  • MultisetGenerator
    • MixtureMultisetGenerator: chooses other generators at random
    • Deal
    • KeepMultisetGenerator: generates multisets with a fixed number of elements and has a keep-tuple
      • CompoundMultisetGenerator: additive union of other KeepMultisetGenerators
      • Pool: Closed under keep-tuple operations apart from some additive unions.
      • Single-hand Deal?

The operations that keep-tuples support are:

• + / additive_union
• * / multiply_counts
• unary -
• [], keep, highest, lowest, middle (non-negative counts only)

[HighDiceRoller]

Things seem ok for now.