Will Tipton Video Pack 2 - Solving Poker
10-05-2014
, 10:48 PM
Quote:
Hi
I dident finish the video serie's for a long time.
But now started again. In video 8 i seem to have a diferent result from Tiptons with the plotEqDistn
my code
i get this result, but compared to Tiptons, he get a diferent curve. with a much more vertical line.
http://i.imgur.com/EOuFsOX.png
Any ideas ?
I dident finish the video serie's for a long time.
But now started again. In video 8 i seem to have a diferent result from Tiptons with the plotEqDistn
my code
Code:
board = pe.string2card(['8d', '6s', '3h', 'Kd', 'Jd']) range1 = Range(1.0) range1.setToTop(0.2, board) range2 = Range(1.0) range2.setToTop(0.8, board) plotEqDistn(range2,range1,board)
http://i.imgur.com/EOuFsOX.png
Any ideas ?
That said, there are lots of things that could lead to an incorrect graph. The ranges could be wrong, the equity calcs could be wrong, the plotting function could be wrong. I wrote up some notes about debugging here:
http://willtipton.com/coding/2014/10/05/debugging.html
(it's an edited version of something I wrote earlier in this thread). Please give that stuff a shot, and if it doesn't fix the problem, it'll lead you to gather some information that will help us figure out what's going on.
10-05-2014
, 11:28 PM
Quote:
I recently was looking at a game tree and was getting some weird results. I wanted to look at a river situation where the river brings four to a straight and the SB has a stronger range then the BB but that the BB still has a decent amount of rivered straights. I gave the BB 3 strategic options. Donk bet 1/3 pot, Donk full pot and check decide. I just wanted to see what the ev difference would be between this and just playing a forced check by the BB.
The wierd part of the result that im getting is that when the BB plays Donk 1/3 Pot that the SB ends up folding 48% of the time. Im not sure whats going on here.
Board: 8s7d6h2c5d
sbStartingRange: AA,KK,QQ,JJ,TT,A9o,A5o,K5o,Q5o,J5o,T9o,T6o,T5o,A9s ,J6s,T9s,T6s
bbStartingRange: A9o,K9o,K8o,K7o,K6o,Q8o,Q7o,Q6o,J8o,J7o,T8o,T7o,A9 s,K9s,K8s,K7s
equity dist:
As you can see bb straights have a large amount of equity with the majority of his range having around 50% equity and then a small portion being total air
Here is the tree:
Pot = 18
Block bet = 6
stacks = 18
maybe I just have an error in the tree im not seeing but the average Evs are
SB average EV:19.1639331148
BB average EV:19.3592594477
So the BB actually has an advantage which is obviously false.
At point 6 in the game tree the SB is folding about 48.38%
Dont really know how anyone can help except maybe someone sees something wrong with my tree?
The wierd part of the result that im getting is that when the BB plays Donk 1/3 Pot that the SB ends up folding 48% of the time. Im not sure whats going on here.
Board: 8s7d6h2c5d
sbStartingRange: AA,KK,QQ,JJ,TT,A9o,A5o,K5o,Q5o,J5o,T9o,T6o,T5o,A9s ,J6s,T9s,T6s
bbStartingRange: A9o,K9o,K8o,K7o,K6o,Q8o,Q7o,Q6o,J8o,J7o,T8o,T7o,A9 s,K9s,K8s,K7s
equity dist:
As you can see bb straights have a large amount of equity with the majority of his range having around 50% equity and then a small portion being total air
Here is the tree:
Pot = 18
Block bet = 6
stacks = 18
maybe I just have an error in the tree im not seeing but the average Evs are
SB average EV:19.1639331148
BB average EV:19.3592594477
So the BB actually has an advantage which is obviously false.
At point 6 in the game tree the SB is folding about 48.38%
Dont really know how anyone can help except maybe someone sees something wrong with my tree?
Spoiler:
and in it's distribution. Your ED shows that BB's range is quite polarized, so it's no surprise he leads river a lot.
That said, your EVs look weird. Is the situation here is that there's 18 in the pot and 18 behind at the beginning of the street? Then there's 54BB in play, and your average EVs should add up to just about 54BB as well, but they don't. Check that you aren't affected by the errata, but there may be some other issue here as well.
Quote:
So I think I figured out what was going on with my original model. The SB in that model just had too many 0% equity hands in his range so even though his range had an overall equity advantage over the BB when the BB chose to have a block bet as part of his strategy the SB was forced to fold a large amount (~ 42% over 300 iterations). Then He chose the rest to bluff raise with. When I did a different simulation on the same board with different ranges where the worst part of the SB range actually had some equity than I got a lot more reasonable results. Even with a more realistic range however I did find that the BB even with a equity disadvantage greatly increased his EV by including a block betting range on this board texture.
10-05-2014
, 11:32 PM
Quote:
I believe it was a different error message although it was a couple weeks ago that I tried so I cant remember exactly. I did follow all of the steps Will laid out and everything seemed to go smooth but I got the error when I tried to import pokereval as well. fwiw I am using anaconda and didnt try and do the installation with a different version.
10-07-2014
, 10:44 AM
I think that what you want to do is to project the probability on each hand of villain's range: (of course villain range is adjusted so to avoid conflicts with hero's hand [i,j] and nature's cards that can be dealt as well)
proba(nature deals card c) = sum on all h(proba(nature deals card c knowing that villain plays hand h) * proba(villain plays hand h))
Villain's range is the one before nature's move so those events are independent.
In case every card can be dealt with equal frequency:
proba(nature deals card c knowing that villain plays hand h) = 1/numCards if no conflicts and h not in nature's possible cards, 1/(numCards-1) if no conflicts and one card of h in nature's possible cards, 1/(numCards-2) if both cards of h in nature's children and no conflicts, 0 if hand h conflicts with card c.
proba(villain plays hand h) = villainRange.r[h]/villainRange.getNumHands
In the 7d,8d,9d,Td,Jd,Qd example:
hero's range is 7d8d, villains range is Td9d,Jd9d
4 possible dealt cards, 9d,Td,Jd,Qd
proba(9d) = 0 obv (both hands conflict)
proba(Td) = 0*.5 + (1/(4-2))*.5 = .25
proba(Jd) = (1/(4-2))*.5 + 0*.5 = .25
proba(Qd) = (1/(4-2))*.5 + 1/((4-2))*.5 = .5
This way of thinking can easily be extended to more general cases with different frequencies.
I rarely post on 2+2 so I would like to use the space for a little announcement...
I am doing lots and lots of stuff starting from Will's videos (thanks again for the material!) but could definitely use some help. It would probably be more fun too
It would be either collaborative with a mid high stakes poker player like myself, who obv would have already worked a bit on will's vids, or it would be a remunerated job with a highly technical person. (I have been in many tehnical directions and lost a lot of time on some subjects, like parallel computing for instance). Please pm me, thanks! (and no scammer, oh well poker these days
)
10-09-2014
, 12:39 PM
Quote:
Sorry for the long delay here. So... I've gone with method 1.
So, IIRC, the reason we used set_hands_with_conflicts() was, in the end, to find out the number of hands in Villain's range for all of our possible holdings. There are a lot of ways to do that, many of which are slow. Here's one idea for doing it fast:
- For each of the 52 cards, have a list of all the hands that conflict with that card. (You only have to make these lists once.) (Notice that there are 51 such hands for each card.) (When I say a list of hands, I mean a list of indexes into your array of length NUM_HANDS.)
Then, when we want to know how big a particular villain range is for each of our holdings (e.g. if we put that answer in an array of length 1326 named result):
- Initialize all entries of result to be the number of hands in Villain' range without card removal effects considered (i.e. just summing up all the fractions).
- For each of the 52 cards
- Count the number of hands in Villain's range it conflicts with using your pre-computed lists of conflicting hands.
- Then subtract off that count from each entry in answer that conflicts with that hand, again using your precomputed list.
- Finally, add back to each entry of answer the fraction of hand in villain's range (that is, in vector notation answer = answer + villainRange), since we subtracted that fraction off twice.
Previously, I think we called something like getNumHandsWithoutConflicts() for each hero hand, and that function added up all the entries in Villain's range, checking each time for a conflict. So, those operations in total took time proportional to NUM_HANDS squared. This method takes time proportional to just NUM_HANDS. Much faster.
So, IIRC, the reason we used set_hands_with_conflicts() was, in the end, to find out the number of hands in Villain's range for all of our possible holdings. There are a lot of ways to do that, many of which are slow. Here's one idea for doing it fast:
- For each of the 52 cards, have a list of all the hands that conflict with that card. (You only have to make these lists once.) (Notice that there are 51 such hands for each card.) (When I say a list of hands, I mean a list of indexes into your array of length NUM_HANDS.)
Then, when we want to know how big a particular villain range is for each of our holdings (e.g. if we put that answer in an array of length 1326 named result):
- Initialize all entries of result to be the number of hands in Villain' range without card removal effects considered (i.e. just summing up all the fractions).
- For each of the 52 cards
- Count the number of hands in Villain's range it conflicts with using your pre-computed lists of conflicting hands.
- Then subtract off that count from each entry in answer that conflicts with that hand, again using your precomputed list.
- Finally, add back to each entry of answer the fraction of hand in villain's range (that is, in vector notation answer = answer + villainRange), since we subtracted that fraction off twice.
Previously, I think we called something like getNumHandsWithoutConflicts() for each hero hand, and that function added up all the entries in Villain's range, checking each time for a conflict. So, those operations in total took time proportional to NUM_HANDS squared. This method takes time proportional to just NUM_HANDS. Much faster.
I've made the following changes to the original code:
1) I'm now using 2D equity arrays and 1D range data
2) I'm using the conflicts dictionary from Emus (thanks!) above in set_hands_with_conflicts()
3) I've replaced get_num_hands_no_conflicts() with get_range_size_no_conflicts() which performs the calculation you suggest
4) I've replaced the relevant code in set_max_evs_at_villain_dp() and set_max_evs_at_nature_dp() so that one call is made to get_range_size_no_conflicts() to create the range size data before the loop over all hands, rather than within that loop. Within the loop I just look up the relevant range size.
I used the original turn spot from the videos to test the speed change. I performed 300 iterations. Please see the %prun data below. The original non-optimised code is first.
So the time taken is down from roughly 1100 seconds to 700 seconds. Is that the size gain you would expect?
I'm now calling set_hands_with_conflicts() 6,000,000 times rather than 18,000,000 times. It is called by get_equity_vs_range() so I guess that's why it remains a large part of the runtime.
But it still takes almost the same amount of time as before! I don't understand that. Any ideas?
FWIW here's my set_hands_with_conflicts() function:
Code:
# conflicts_dict is a dictionary as provided by Emus earlier in the thread
def set_hands_with_conflicts(hand_array, cards_list, num):
for c in cards_list:
for i in conflicts_dict[c]:
hand_array[i] = num
10-10-2014
, 04:29 AM
Quote:
Thanks Will.
I've made the following changes to the original code:
1) I'm now using 2D equity arrays and 1D range data
2) I'm using the conflicts dictionary from Emus (thanks!) above in set_hands_with_conflicts()
3) I've replaced get_num_hands_no_conflicts() with get_range_size_no_conflicts() which performs the calculation you suggest
4) I've replaced the relevant code in set_max_evs_at_villain_dp() and set_max_evs_at_nature_dp() so that one call is made to get_range_size_no_conflicts() to create the range size data before the loop over all hands, rather than within that loop. Within the loop I just look up the relevant range size.
I used the original turn spot from the videos to test the speed change. I performed 300 iterations. Please see the %prun data below. The original non-optimised code is first.
So the time taken is down from roughly 1100 seconds to 700 seconds. Is that the size gain you would expect?
I'm now calling set_hands_with_conflicts() 6,000,000 times rather than 18,000,000 times. It is called by get_equity_vs_range() so I guess that's why it remains a large part of the runtime.
But it still takes almost the same amount of time as before! I don't understand that. Any ideas?
FWIW here's my set_hands_with_conflicts() function:
I've made the following changes to the original code:
1) I'm now using 2D equity arrays and 1D range data
2) I'm using the conflicts dictionary from Emus (thanks!) above in set_hands_with_conflicts()
3) I've replaced get_num_hands_no_conflicts() with get_range_size_no_conflicts() which performs the calculation you suggest
4) I've replaced the relevant code in set_max_evs_at_villain_dp() and set_max_evs_at_nature_dp() so that one call is made to get_range_size_no_conflicts() to create the range size data before the loop over all hands, rather than within that loop. Within the loop I just look up the relevant range size.
I used the original turn spot from the videos to test the speed change. I performed 300 iterations. Please see the %prun data below. The original non-optimised code is first.
So the time taken is down from roughly 1100 seconds to 700 seconds. Is that the size gain you would expect?
I'm now calling set_hands_with_conflicts() 6,000,000 times rather than 18,000,000 times. It is called by get_equity_vs_range() so I guess that's why it remains a large part of the runtime.
But it still takes almost the same amount of time as before! I don't understand that. Any ideas?
FWIW here's my set_hands_with_conflicts() function:
Code:
# conflicts_dict is a dictionary as provided by Emus earlier in the thread
def set_hands_with_conflicts(hand_array, cards_list, num):
for c in cards_list:
for i in conflicts_dict[c]:
hand_array[i] = num
11-02-2014
, 09:23 PM
Quote:
Ok well, think about this from a poker perspective for a minute. We're comparing the top 80% of hands on some river board to the top 20% of hands on that river board. Some card removal/chopping effects aside, the bottom 3/4 of that 80% range will lose to every hand in the 20% range. So, the bottom 3/4 of your equity distribution should be stuff with 0% equity. And that's what the correct ED shows:
That said, there are lots of things that could lead to an incorrect graph. The ranges could be wrong, the equity calcs could be wrong, the plotting function could be wrong. I wrote up some notes about debugging here:
http://willtipton.com/coding/2014/10/05/debugging.html
(it's an edited version of something I wrote earlier in this thread). Please give that stuff a shot, and if it doesn't fix the problem, it'll lead you to gather some information that will help us figure out what's going on.
That said, there are lots of things that could lead to an incorrect graph. The ranges could be wrong, the equity calcs could be wrong, the plotting function could be wrong. I wrote up some notes about debugging here:
http://willtipton.com/coding/2014/10/05/debugging.html
(it's an edited version of something I wrote earlier in this thread). Please give that stuff a shot, and if it doesn't fix the problem, it'll lead you to gather some information that will help us figure out what's going on.
Also my 1st graph didn't come out quite right :-/
Idk if it's relevant but the only other bit of code that didn't quite work out right occurred when trying to generate a file name for the pf board 255,255,255,255,255
Any idea on how to fix this? My only thought on it is it's something to do with the preflop.ea.npy file, that you included for us to save time, and the above code. As I 1st started the pack a while ago and have recently come back to it (working again from beginning in a new note book) and had already imported that file. I note that klondi had also retaken up the video pack.
Anyway I'll press on with the rest of the videos as I'm really enjoying the pack. It's not too hard to understand whats going on even for a complete n00b like myself!
Thanks in advance for any help
11-24-2014
, 12:34 PM
If I had to try to optimize python code without that info, it'd be a matter of making sure I know what's going on under the covers when my code runs. E.g., we're using a lot of lists or arrays here. Sometimes when we insert into an array, it has to move all the other numbers over to make space. Or it makes a copy of the array before sticking the new value on the end. Definitely want to make sure nothing like that is going on.
I don't know what support there is for profiling/debugging cython code, but I imagine there is some since performance is pretty much the whole reason for its existence.
edit: yea, so I didn't read all that code, but if it's still a problem for you, and you can provide some profiling info, then lmk and I'll try harder
.
Last edited by yaqh; 11-24-2014 at 12:44 PM.
11-24-2014
, 12:43 PM
Quote:
For the general version:
I think that what you want to do is to project the probability on each hand of villain's range: (of course villain range is adjusted so to avoid conflicts with hero's hand [i,j] and nature's cards that can be dealt as well)
proba(nature deals card c) = sum on all h(proba(nature deals card c knowing that villain plays hand h) * proba(villain plays hand h))
Villain's range is the one before nature's move so those events are independent.
In case every card can be dealt with equal frequency:
proba(nature deals card c knowing that villain plays hand h) = 1/numCards if no conflicts and h not in nature's possible cards, 1/(numCards-1) if no conflicts and one card of h in nature's possible cards, 1/(numCards-2) if both cards of h in nature's children and no conflicts, 0 if hand h conflicts with card c.
proba(villain plays hand h) = villainRange.r[h]/villainRange.getNumHands
In the 7d,8d,9d,Td,Jd,Qd example:
hero's range is 7d8d, villains range is Td9d,Jd9d
4 possible dealt cards, 9d,Td,Jd,Qd
proba(9d) = 0 obv (both hands conflict)
proba(Td) = 0*.5 + (1/(4-2))*.5 = .25
proba(Jd) = (1/(4-2))*.5 + 0*.5 = .25
proba(Qd) = (1/(4-2))*.5 + 1/((4-2))*.5 = .5
This way of thinking can easily be extended to more general cases with different frequencies.
I think that what you want to do is to project the probability on each hand of villain's range: (of course villain range is adjusted so to avoid conflicts with hero's hand [i,j] and nature's cards that can be dealt as well)
proba(nature deals card c) = sum on all h(proba(nature deals card c knowing that villain plays hand h) * proba(villain plays hand h))
Villain's range is the one before nature's move so those events are independent.
In case every card can be dealt with equal frequency:
proba(nature deals card c knowing that villain plays hand h) = 1/numCards if no conflicts and h not in nature's possible cards, 1/(numCards-1) if no conflicts and one card of h in nature's possible cards, 1/(numCards-2) if both cards of h in nature's children and no conflicts, 0 if hand h conflicts with card c.
proba(villain plays hand h) = villainRange.r[h]/villainRange.getNumHands
In the 7d,8d,9d,Td,Jd,Qd example:
hero's range is 7d8d, villains range is Td9d,Jd9d
4 possible dealt cards, 9d,Td,Jd,Qd
proba(9d) = 0 obv (both hands conflict)
proba(Td) = 0*.5 + (1/(4-2))*.5 = .25
proba(Jd) = (1/(4-2))*.5 + 0*.5 = .25
proba(Qd) = (1/(4-2))*.5 + 1/((4-2))*.5 = .5
This way of thinking can easily be extended to more general cases with different frequencies.
The main reason I made it possible to give an arbitrary a priori probability of a card being dealt (other than just 1/num-cards-left-in-the-deck) is to help set up model games. E.g. if we're on the turn, and there's a flushdraw out, and we want a cheap model that includes play on flushing and non-flushing rivers, then maybe we just make a decision tree with two rivers (one flush and one not), but give the two cards different probabilities of being dealt...
Quote:
I rarely post on 2+2 so I would like to use the space for a little announcement...
I am doing lots and lots of stuff starting from Will's videos (thanks again for the material!) but could definitely use some help. It would probably be more fun too
It would be either collaborative with a mid high stakes poker player like myself, who obv would have already worked a bit on will's vids, or it would be a remunerated job with a highly technical person. (I have been in many tehnical directions and lost a lot of time on some subjects, like parallel computing for instance). Please pm me, thanks! (and no scammer, oh well poker these days )
I am doing lots and lots of stuff starting from Will's videos (thanks again for the material!) but could definitely use some help. It would probably be more fun too
It would be either collaborative with a mid high stakes poker player like myself, who obv would have already worked a bit on will's vids, or it would be a remunerated job with a highly technical person. (I have been in many tehnical directions and lost a lot of time on some subjects, like parallel computing for instance). Please pm me, thanks! (and no scammer, oh well poker these days
)