More Computer Discussion

We have certainly had much discussion concerning the merits of computer simulation as it applies to hold 'em. Without repeating all the arguments let me just say that limit hold 'em is a game that does not simulate well. This has a lot to do with the fact that players frequently fold early in the hand, many strategies are counter intuitive, many concepts seem to contradict each other, and alternate strategies are frequently available throughout the hand for a skilled player. So because of this, despite what one poster has said below, I have never used or endorsed any type of simulations for hold 'em. (I believe that the same is true of David as well.)


But hold 'em isn't the only form of poker that is played. Way back in 1984 I wrote a series of articles called "Killing the Pot" which discussed when it was correct to either "look at two" or "look at three" and kill in California ace-to-five draw lowball games (played with a joker) and many of my conclusions were based on computer simulations. (It was a program that I wrote and ran on an old Apple 2E computer.) So I am aware of their value when the situation is appropriate. (For thoose interested the articles are now a section in my book WINNING CONCEPTS IN DRAW AND LOWBALL.)


Anyway, this brings me to my purpose of this post. Seven-card stud, unlike hold 'em, is a game that simulates very well. This has to do with the fact that it is often correct to chase and that basic play is much more mathematical than hold 'em. That's because slight changes in the number of active players and/or in the exposed cards can dramatically impact the value of a hand. In the 21st Century edition of SCSFAP we have a whole appendix of stud hand simulations, and both David and I learned from these simulations and incorporated this knowledge into the book. (In fact, I have been told privately that one of our vocal hold 'em critics admits that SCSFAP-21 is the best poker book.)


So what is it that I am driving at? It is the fact that there is still probably a fair amount to learn about stud and that this future knowledge will come mainly from simulations.


Now we seem to have a forum that contains a few people who are highly skilled programmers. Furthermore, they are critical of my attitudes about hold 'em simulations. But I know better. I know that if they really understood poker well, they would take their skills and attack stud, and attack it like it was never attacked before. Of course it is harder to become a stud expert than it is to be a hold 'em expert; and there are more hold 'em games -- especially at the middle limits and in most geographic areas -- then there are stud games. But if you really want to become a poker expert, and you have the proper computer/programming skills, stud should be the way to go. So I'll be seeing many of you at the stud tables in the future.

>>Furthermore, they are critical of my attitudes about hold 'em >>simulations.


I, for one, am not critical of your views about hold'em simulations.


You've got it exactly right, and that's the challenge that makes the whole attempt worthwhile to try.


>This has a lot to do with the fact that players frequently fold early in the >hand, many strategies are counter intuitive, many concepts seem to >contradict each other, and alternate strategies are frequently available >throughout the hand for a skilled player.


Very true.


But counter intuitive strategies and contrary concepts can be programmed.


>>But I know better. I know that if they really understood poker well, they >>would take their skills and attack stud, and attack it like it was never >>attacked before.


Well, it really depends on the programmer's motives.


Let me bore you with mine.


1. Don't want to sell software.


2. Don't want to write books or articles.


3. Seven card stud, I'm sorry to say, puts me to sleep.


4. Don't care about tournaments or ring games above 15/30.


5. Only goal was to be the favorite, most of the time, in a 10/20 game.


I still don't understand poker well, but I've met my goal.

"But counter intuitive strategies and contrary concepts can be programmed."


While I agree that they can be programmed, you have to first understand them well to do the job. If this is the case, the need for programming hold 'em is greatly reduced since you already know the answer you are looking for.


"3. Seven card stud, I'm sorry to say, puts me to sleep."


This might be because you are playing "little stud" as opposed to "real stud." Once you start playing $15-$30 and higher, where the ante becomes a significant part of your game, it is no longer boring once you know how to play reasonably well.

Back to Hold'em for a sec, Ken Warren says in his low-limit book that computer analysis has proved that preflop raising does not prove to be profitable except for the three pocket pairs. Don't quite understand because preflop raising thins the field, even in low limit, so a hand like AK or AQ should be good to raise with right?

"So because of this, despite what one poster has said below, I have never used or endorsed any type of simulations for hold 'em. (I believe that the same is true of David as well.)"


In a book entitled _Omaha Holdem Poker_ by Bob Ciaffone (1984 version) on page 30 there are a bunch of showdown numbers for hands produced by Mike Caro's Poker Engine and run by Mason Malmuth. Are you saying that isn't at least a partial endoresement of the use of simulations?


With pot equity so well defined by the flop in Omaha I have a hard time imagining that the types of problems you've attributed to HE showdown simulations don't also apply to Omaha showdown simulations.


I have seen David suggest the use of Poker Probe to get a feel for a problem. I would consider that endorsing the use of simulation.


mph

Mason,


I know how to play poker, and I am pretty skilled at programming.


For my own enjoyment, I have been working on a holdem program, and I have been corresponding some with Aaron of U of Alberta, who runs the U of Alberta poker server, and who is author or co-author of Poki.


I have spent less than two months, very part-time, working on it. I have modelled it after some of the design ideas encapsulated in Wilson TTHE: Tables for pre-flop (dynamically modifiable depending on the game conditions) and tables for a large number of post-flop conditions. This is NOT the programming design of Poki at all, in fact is is purposely designed very differently than Poki, which tries to predict the opponents cards. (I am too impatient to program it with predictors, I did something different, see below). I have learned a lot.


Here are a few comments:


1. My program has played about 20000 hands against humans and against Aarons programs. It is winning modestly. About $14000 at 10-20 with no rake. After rake, it would be winning about half that amount. Aaron's programs do better.


2. It stays about 20% preflop.


3. It plays way better than I do (yeah, it beats me) and I am winning very consistently online at 5-10 for real $$$. And I win at Casinos.


4. Here is the main interesting point to me: Since I modelled it in a way after tables which I knew well from TTHE (Wilson is a genius for these representations), I picked the tightest pre-flop and the toughest and most agressive postflop of his model styles for my program. Both Poki and I could outplay this model. Why?


It was too predictable and, even though very aggressive by most standards (read 'Lash'), it was too passive.


I made it unpredictable. It does some very interesting and unpredictable things. Not enough yet, but still they are not easily figured out and they are semi-random.


I made it very aggressive. As Izmet says "folding is a disease."

You better prove to my program that it is behind for it to fold.

And it tries to push the opponents.


It does not try to figure out the opponents hands themselves: Instead, it takes the opponents actions as symbols for what strength the opponent has and acts accordingly. It also has symbols for what to do with its own hands and draws and busts, and these actions (bet, raise, call) may be the same for very different conditions to try to fool the opponent.


There is a lot more, but mostly I think that a well thought out program, written by someone who knows poker and programming, who put a lot of time into it, as Aaron and others at Alberta have, could play at high levels. My program needs a lot more work, I have little time, and I have no real way to test against real money games, so I do not claim to be able to do much more than learn. Oh, by the way. my own win rate has gone up and up as I worked on this program....


Just my two cents...


Mark

>>Oh, by the way. my own win rate has gone up and up as I worked >>on this program....


Yes, this is the main value of writing, from scratch, your own ring game program.


It would be almost impossible for you not to have more useful

patterns stored in your head than anyone else at the table.

"Are you saying that isn't at least a partial endoresement of the use of simulations?"


No. I have never endorsed the use of simulations for hold 'em.


Omaha is a different game. However, they might be a little better for this game than hold 'em since many people (at least in 1987, not 1984) when this work was done were seeing the flop in this game.


Sorry, but you'll just have to try again. As for David, I suggest that you talk to him, not to me. But one thing for sure, in any of the work that we have done together, which is quite a lot, we have never used hold 'em simulations.

Erin,


Yes, that is part of it. But the double and triple benefit of it was the real understanding -- from working on just a first level of enhancements -- of aggressive play. I cannot explain it too well but my original code (run from dynamic tables), which looked pretty strong and solid (again, think 'Lash'), were too timid in so many cases. They missed extra bets, they folded so many times when they shouldn't have. This helped my own play so much.


Mark

showdown numbers arent simulation, they are just calculation.

Mostly untrue. Showdown numbers between a small number of known HE hands can be done combinatorially. Showdown simulations involving a full table with random hands are done via monte carlo simulation methods [1]. What you are confusing is the fidelity of the simulation with whether its a simulation.


mph


[1] They could be 'calculated' as you state, but so could higher fideltity simulations. Its just the complexity of doing those calculations that drive users towards monte carlo simulation.