-
Notifications
You must be signed in to change notification settings - Fork 4
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
Possible expression overhaul? #178
Comments
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:
Unfortunately, while the first two can be combined into a single 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 Should this be a separate class, or integrated under Should Can/should we use this to take advantage of known multiset sizes? |
Possible class hierarchy:
The operations that keep-tuples support are:
|
evaluator(x)
within amultiset_function
, you have to dox.evaluate(evaluator=evaluator)
.It would be nice to be able to appendDie
operations to the end. This would seem to require either using__getattr__
, which is potentially dangerous, or adding expression versions for allDie
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.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.
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.The text was updated successfully, but these errors were encountered: