nalkpas/hand-simulator

simulating MTG hand distributions w/ brute force MCS

hand-simulator

Usage

hand.py contains a Hand class that accepts a filename as input, generates a deck from the given file, and generates hands from that deck. It supports several functions:

new_hand(size)

Generates a new hand of the given size, contained within the Hand object, and returns a copy. Defaults to 7.

contains(cards)

Accepts the name of a card or a list of names, returns 1 if the current hand contains any of those cards, 0 otherwise.

count_of(cards)

Accepts the name of a card or a list of names, returns the total number of those cards in the current hand.

expect(cards, size)

Accepts the name of a card or a list of names and a hand size, returns the hypergeometric expectation of those cards in a hand of the given size.

set_deck(new_deck)

Accepts a filename, a list of individual cards, or a dictionary of card names and quantities. Sets the deck and decklist to the input.

get_deck()

Returns a copy of the internal deck, a list of individual cards.

get_decklist()

Returns a copy of the internal decklist, a dictionary of card names and quantities.

has_tron()

Returns whether the current hand contains Tron, counting the first Expedition Map. Will be deprecated when I find the motivation.

Examples

grixis_mana.py, grixis_mana_full, eldrazi_tron.py, and affinity.py contain applications. They all work essentially the same way. The main thing is implementing logic to classify the kinds of hands you're looking for.

grixis_mana.py tests to see how often checklands come into play untapped with a standard Grixis energy manabase. grixis_mana_full tries to find the optimal grixis manabase given a set of parameters that characterize an utility function. eldrazi_tron.py finds how often Eldrazi Tron gets its best draws. affinity.py finds how often Affinity plays a 2- or 3-drop on turn 1.

hand-simulator's Issues

Open with wb

Is there a reason you open with wb rather than just w, I was running the code myself and it wouldn't run unless I removed the b parameter on the write.

Monte Carlo, expected value, and hypergeometric discrete RV

Cool project. I found this through Alex Majlaton's article on CFB.

So I was having some trouble looking through the source and figuring out where the Monte Carlo method is used. But now I see that you're using this hypergeometric discrete random variable (RV) from SciPy. So I would think that the Monte Carlo method would require you to sample realizations of the RV and use the law of large numbers to estimate the mean. But I see that you simply call hypergeom.mean. Looking through the SciPy hypergeom source code, I am not easily understanding where they compute the mean. If you are interested in taking the time, could you maybe explain how you get from this RV to the results you talk about in your blog post?

Thanks!

P.S. I tend to use issues to document all sorts of things like this, not just bugs in my code. My apologies if you wanted to keep your issues empty. Let me know if there's a better way to communicate :)

P.P.S. I hadn't ever seen this hypergeomtric discrete RV. I had put a bit of thought into how I might want to do a project like this a while back, but never actually implemented anything (though I've used Monte Carlo for some engineering stuff). This looks like a really useful part of SciPy that I'll be keeping in mind.

[E-Tron] Condition for two temples

currently, the condition for two temple & thing hand is (see here):
(temples + has_Map >= 2) * (lands < (7 - j))
This could be a 1 temple, 1 map N spells hand and should be discarded.

I think the proper implementation would be
((temples >=2) or ((lands >=2)*(temples + has_Map >= 2)))* (lands < (7 - j))