robert-7 / gambit Goto Github PK

Change

<NashProfile for 'PSP Game with 2 players and 3 cards': [[Fraction(1, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1)], [Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(1, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1)]]>
<NashProfile for 'PSP Game with 2 players and 3 cards': [[Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(1, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1)], [Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1), Fraction(1, 1), Fraction(0, 1), Fraction(0, 1), Fraction(0, 1)]]>

To

<NashProfile for 'PSP Game with 2 players and 3 cards': [[1, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 1, 0, 0, 0]]>
<NashProfile for 'PSP Game with 2 players and 3 cards': [[0, 0, 0, 0, 1, 0, 0, 0], [0, 0, 0, 0, 1, 0, 0, 0]]>

We know we want to use this method on all similar subtrees. However, we want to test it on the flop subtrees first. We'll then compare times and see how useful it is before applying this to all subtrees.

When Player 1 bets, Player 2 should be able to raise. When Player 1 checks, Player 2 should be able to bet. Moreover, Player 1 needs to have a response to this. Therefore, Player 1 should be able to Call or Fold in either of these two cases.

Acceptance Criteria: Look at the branch created for a simple subtree. It should look correct and it should be small enough to be opened in the Gambit program.

Remove Actions 4, RIVER card, and Actions 3. You should see a slightly more complex tree. However, it should still be openable in Gambit and you should still verify it works.

The user can input a string that identifies the node. That is, if the user inputs the string, say,

C5-X0-Y1-C2-X1-Y0-T

Or

C5-X0-Y

The program should recognize the node that is being mentioned.

Change

<NashProfile for 'PSP Game with 2 players and 3 cards': [[1, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 1, 0, 0, 0]]>
<NashProfile for 'PSP Game with 2 players and 3 cards': [[0, 0, 0, 0, 1, 0, 0, 0], [0, 0, 0, 0, 1, 0, 0, 0]]>

To

Strategy A: Rose should never bet while Colin should call 100% of the time if he has a 4.
Strategy B: Rose should bet 100% of the time if she has a 4 (and she should fold otherwise) while Colin should call 100% of the time if he has a 4 (and he should fold otherwise).

Right now, we compute the winner for every terminal node. This occurs 4 times (for each terminal node preceeded by a call/check action). Therefore, we should only do it once and pass it in as an argument.

This should be doable. For every number from 1 - 7426, get the hand that maps to it, and remove the number if the hand is not a valid hand with your deck.

In actual poker, there is no set ante for both players to participate in the game. In actual poker, a chosen player, say player 1, is the small blind and posts half the ante, while the big blind, player 2, posts the ante. Player 1 then has the choice to check or bet. The rest of the action round is identical to others.

Approach:

ASSUME bet_round=0
if outcome == (0,0):
    impossible (that would imply both people 
if outcome == (0,2)
    return ...
etc.

It would be a good idea to try the program outside of a virtual machine for efficiency -- but also so other people can try the program as well.
Here's the link: http://www.pyinstaller.org/

pip install pyinstaller

This is hugely important if we want to print out the subtree AND be able to solve it.

We need a round of betting after the turn card is played

Acceptance Criteria: Look at the branch created for a simple subtree. It should look correct and it should be small enough to be opened in the Gambit program.

Jason sent an email telling you the ranking we'd like to use.

This should do it

This sounds like a "Nice to have". However, this really helps us with the next task which allows us to specify the actions taken between cards being dealt -- a necessary task that allows us to narrow down which subtree we want to look at.

The game isn't complete. Currently, the game is made such that Player 1 and Player 2 know each others' hands and that's because I haven't implemented information sets yet.

We'd like to create a game tree for a simple 2-person game.

We'd like to create a game tree for a simple game of poker. This will consist of:

• There will be two players
• Each player will get 2 hole cards
  • ISSUE: They currently see each others hands! This is because every node is its own infoset. (See #12)
• There will be 1 round of betting
  • Player 1 will have the choice of betting a fixed number or checking after receiving his cards
  • Player 2 will have the choice of calling or folding if Player 1 bets
• The flop will be revealed.
• The appropriate winner will be declared.
  • ISSUE: The appropriate winner is not chosen. We currently use the deuces library which assumes you're using a full deck and is basing the ranking of the hand on that. (See #15)

NUMBER_OF_SUITS = 3
LOWEST_CARD = 13
=> deck = ["Kc", "Kd", "Kh", "Ac", "Ad", "Ah"]

get_order(["Kc", "Kd"] = [0,1]) ==> 0
get_order(["Kc", "Kh"] = [0,2]) ==> 1
get_order(["Kc", "Ac"] = [0,3]) ==> 2
get_order(["Kc", "Ad"] = [0,4]) ==> 3
get_order(["Kc", "Ah"] = [0,5]) ==> 4

get_order(["Kd", "Kh"] = [1,2]) ==> 5
get_order(["Kh", "Ac"] = [1,3]) ==> 6
get_order(["Kh", "Ad"] = [1,4]) ==> 7
get_order(["Kh", "Ah"] = [1,5]) ==> 8

get_order(["Kh", "Ac"] = [2,3]) ==> 9
get_order(["Kh", "Ad"] = [2,4]) ==> 10
get_order(["Kh", "Ah"] = [2,5]) ==> 11

get_order(["Ac", "Ad"] = [3,4]) ==> 12
get_order(["Ac", "Ah"] = [3,5]) ==> 13

get_order(["Ad", "Ah"] = [4,5]) ==> 14

You may need to recreate the program in tree-based model?

We need a round of betting after the flop cards are played

It's very easy to accidentally input two of the same cards, leading to errors popping up late in the code with little explanation.

This allows us to specify the actions taken between cards being dealt -- a necessary task that allows us to narrow down which subtree we want to look at.

For the time being, we just need to need to ensure we haven't broken anything.
Acceptance Criteria:
The output should remain unchanged, given the change to the config.ini file. Therefore, the output should be equal to this file.

We don't need the variable since node.player == None tells us the node must be terminal.

We should just be able to read the arguments we want for the current game from a configuration file. This will cut down on unnecessary line edits to the main files.
https://docs.python.org/2/library/configparser.html

https://mathema.tician.de/software/pycuda/

We need to create the branches that indicate all possibilities for a river card.

We want to catch bad values early on. Examples:

• We want to check that HOLE and FLOP cannot be given less than 4 and 3 cards, respectively.
• We need to check that if a river is given, then a turn must be given, and so on...

This isn't NECESSARY. However, in our code, if we repeatedly call the return_winner function, then we'll constantly be recreating the mapping for aces_wrapping. However, this function will be called many times. Therefore, this would be a large benefit to the execution overall.

We need to create the branches that indicate all possibilities for a turn card.

It's quite evident that gambit slows down a lot as it creates the subtrees. Consider using the the copy_tree(node) method to copy trees over and then attach payoff outcomes to the terminal nodes. It's reasonable to assume this should speed things up since I'm sure the tree_copy method is optimized for this scenario.

Link:http://www.gambit-project.org/gambit15/pyapi.html#gambit.Node.copy_tree

We'd like to specify whether the ace wraps around (specifically if our lowest card is not a 2), and if so, the ranking should be adjusted accordingly.

Therefore, when ACE_WRAPS is true, a hand with cards [Ac, 6h, 7h, 8h, 9h] should count as a straight. Otherwise, it's just [6h, 7h, 8h, 9h, Ac] which is an Ace-High.

For visualization purposes, and because our algorithm isn't that efficient, we'd like to be able to print out and visualize a single subtree as it's own game.

We currently don't uniquely determine expected/actual payoffs for nodes because we don't take into consideration all possible actions.

This is blocked by the relabeling of actions.

Right now, this is a sample terminal node:

t "C1004-A0-B0-A0-C19-A0-B0-A0-C1-A0-B0-A0-C0-A1-B1-T - Terminal node. No More Rounds." 0

The 0 at the end of the line implies the outcome is zero (well, in our code, there is no outcome assigned, yet, so I'm not sure if there's a default value assigned). The point is, we need to assign a payoff.

We need a round of betting after the river card is played