Cool, so... how do you do it in PT4, in case anyone asks in the future?

Yes, I didn't include ranges of most actions that are very rarely taken. I think those figures take up enough space already .

I don't think this is really an issue. If this were the case, then we'd notice because the EVs of the actions would still be different. Re: suited and unsuited hands, suited is not always strictly better than unsuited -- it's more complicated than that.

So you're assuming that our marginal 3-bet defending hands capture 35% of the pot vs villain's value and 85% of the pot vs his 3-bet bluffs? I agree with Befeltingu12 that that's probably a bit too ambitious. Maybe something like 25 and 50% would be more reasonable, which I believe leads to V=80%. Anyway, as we see later, this model isn't super appropriate for preflop play.

Yea, the 1/3 number is an error. Naively, a half-pot bluff (e.g. 3BB into a pot of 6BB) will need to work 1/3 of the time for us to break even, and thats the number I had stuck in my head, but as stevepa described above, the result for raises is different. Here, risking 6BB to win 6BB -> 50%. Thanks for pointing out the errata.

Suppose we flop a weak made hand in the SB and have a cbetting decision. If our poker client had a button that said "immediately show down, skipping turn and river action", we'd probably usually want to click it. Future rounds of betting won't usually help us capture more of the pot on average. So, that would be the most profitable way to play those hands at the same time that betting was the best play with other hands. Ofc there's no such button, but maybe just trying to check down is almost as good if Villain plays passively vs missed cbets. If he doesn't, maybe our most profitable strategy involves cbetting those hands and/or slowplaying strong ones.

Video pack is out!

Yea, 58+44+more is definitely too many percents. The 58 should be 54.

Well, it's kind of a big deal :/. Here's the correct Figure 14.27:

Yea I forgot to include it originally, but it should be there now. Glad you're enjoying the videos!

Yea, it's a copy protection thing. We decided it wouldn't be too inconvenient for people here, since these videos really need to be watched at a computer anyway.

I took a look at some briefly. The format of their hand histories is weird, so I wrote a converter to make them look like Stars HHs so I could look at them in TTVis. Was interesting to see how they play, but I'm not sure they're strong enough players that it makes sense to try to emulate them. I'm also not super interested in 200BB play, personally.

I believe all the errors I know of are mentioned in this thread. There'll be an official errata on the book's webpage after a bit more time passes.

Yep it is there now, thanks. I must say I'm enjoying them less now after a mistaken set of quotes and writing iDecPt instead of iChild in one equation cost me the last 2.5 hours of my life It's good you left your debugging in the videos or I may have never found my mistakes.

Hah, yea, unfortunately debugging's an unavoidable part of programming. I think time spent practicing is time reasonably well spent, even if it can be frustrating.

Um, maybe a couple other fyi type things about preventing bugs and debugging, in case anyone's interested:

- There are things called debuggers which basically let you execute programs one line at a time -- seeing what functions are called when, the values of all the variables at every point, etc. Very useful in figuring out what's going wrong. iPython has some debugger features built-in.

- Testing functions is an important part of software development. It's not a bad idea at all to just think of writing some tests for a function as basically just part of writing the function in that you always do it. Of course tests help you make sure that the code works correctly when you write it, but at least as importantly, it gives you an easy way to check if changes you make in the future break anything.

Just finished book 2 and am eager to get into the videos.

Read somewhere the author is a doctoral candidate. Seriously doubt its in poker but this book could easily qualify as a magnum opus nonetheless imo.

This might be the best non fiction book I have ever read, kudos.

Hey. I already sent message to Will but ill post it here as well just to maybe get any thoughts on this faster.
Its about Equity Array video. When i wrote the code i got this ugly error

It points out that my 4 dimentional array is too big. But Will didnt have any problems in his video. Any thoughts?

Ya should be numCards instead of numHands

hey it all started to work but i have following question. When i created that .npy file for 863K board it took 57 MB of my computers memory. And that is just 1 board. There are countless combinations of boards and i cant give them all 57 MB. Also you told that creating preflop file would take about 1-2 months. Why is that file so small (also 57 MB) ? Just 100 combos of diferent boards would take 5GB's of space. Am i understanding something wrong?

minotaurs, I am by no means an expert but I'll take a shot.

Why is that (preflop) file so small?
All the files should be the same size, they are essentially the same. Each is a 52x52x52x52 array filled with equity numbers (which are between 0 and 1.)

For the preflop file, those equity #s take much longer to calculate because the program needs to run through every 5 card runout for every hand vs every hand instead of just every turn/river runout for filling a flop array. Quick #s: there are 2,598,960 different 5 card runouts, 1176 different turn/river cards for a given flop, so the preflop equity array should take about 2210 times as long to create as a flop equity array, but the files will be the same size.

Just 100 combos of diff boards would take 5GB's of space. Am I understanding something wrong?
That is correct. But you can always erase the equity array after you're done with the spot, it will get remade if you ever go back to it. Just don't erase the preflop one as that one takes forever to build.

No longer a candidate -- I graduated! Thanks for the kind words.

Yup, a 1326x1326x1326x1326 array is waaay bigger than a 52x52x52x52 array.

Yup, thanks for the good explanation Steve.

Worth reiterating something that was mentioned a couple times in the vids -- you can reduce that memory usage by a couple factors of two pretty easily if you represent the data differently.

Tnx guys every1 for responses Im also really enjoying video pack so far and the best is yet to come