Indistinguishable / sorted multideal; tuple evaluators

[HighDiceRoller]

This would reduce the source state space by a factor of up to the factorial of the hand size. The highest I've seen commonly is 4 hands, which comes out to 24-fold.

• What if we only want some of the hands to be distinguishable?
• Same thing but for pools?
• It doesn't seem possible to produce the same sorting for both ascending and descending pop order, since this would involve future information.
• Can we just add some equivalence classes to MultiDeal? The proposed equivalence class would be the deck and the sorted remaining hand sizes. However, I don't think this works, because we lose the connection to the previously-dealt cards in each index -- in fact, the hands could end up with the wrong number of cards!
• Instead, I think we would have to assign and pin the hands to indexes at the moment they become distinguishable.

Related, is it worthwhile to have tuple evaluators?

• Double any. Though this might be better served by merge + regular any.
• any + a positive-"sticky" bool evaluation / all + a negative-"sticky" bool evaluation. The trouble is that we still need to keep track of which specific hands are invalided / still in the running, so the only possible gain would be after exiting the outcome window, where we can collapse down to just a single bool.
• max_sum: would require non-negative outcomes and counts
• Do we need custom evaluators for every case, or is there any clean way to do some sort of mapping, even if it only supports a limited set of evaluations?
  • I wouldn't put too much effort if it's merely syntactic sugar with no performance benefit; expensive operations should not get special effort to make easy to write.
• More?

[HighDiceRoller]

Initial trials only show ~2x improvement at best. Can this be helped by changing the sort order?

• Started by sorting by hand size / currently emitted count.
• Pop order didn't seem to have an obvious effect.
• Sorting by group size instead didn't seem to have an obvious effect.

[HighDiceRoller]

Example snippet:

# all_deal = deck.deal((10, 10, 10, 10))
# group version
all_deal = deck.deal_groups((10, 1), (10, 3))

# given ace of clubs

@multiset_function
def i_have_ace_of_clubs(a, b, c, d):
    return (a.keep_outcomes([0]).size(),
            (b & [0, 1, 4]).any(),
            (c & [0, 1, 4]).any(),
            (d & [0, 1, 4]).any())

start_time = perf_counter()
result = i_have_ace_of_clubs(all_deal).group_by[0]
elapsed_time = perf_counter() - start_time
print(f'time: {elapsed_time}')

• Before implementation: 2.15 s
• Without groups: 2.30 s
• With groups: 2.20 s

So in this case the gain isn't even enough to offset the implementation overhead.

However, this saw a bigger gain:

deck = Deck([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 10, 10] * 4)

@multiset_function
def blackjack4(a, b, c, d):
    return a >= [1, 10], b >= [1, 10], c >= [1, 10], d >= [1, 10]

hand_size = 2

cProfile.run('blackjack4(deck.deal((hand_size,) * 4))')
#cProfile.run('result = blackjack4(deck.deal_groups((hand_size, 4)))')

• Before implementation: 708 ms
• Without groups: 755 ms
• With groups: 424 ms

The number of sources created does appear to be about proportionally smaller as well, though well short of the hoped factor of 24. Thinking about it some more, it may be that the correct factor is not the reduction in final orderings, but the number of ordered source states each unordered source state represents, in which case by the time all of the hands have been pinned there is no longer any advantage. In the first case, all of the cards get dealt so the pinning would happen pretty early?