Has this been posted yet? I cant seem to find it. Also, what methodology did you use to determine the hand ranking? It is close to mine, but [for pushing ranges at least] seems to favor suited hands slightly more than my rankings do.



It would be very helpful to be able to modify the ranges, or at least get a little more info as to how you arrived at them [if you used the predictive simulation to test different rankings, that would be very helpful to know, as i would probably then switch to yours]. Also, when editing the ranges, it would be helpful to have a text field that lets us input the % instead of needing to use the slider.

This product has a lot of potential and I have bought several licenses for horses, but currently am hungup on the hand ranking issue

Picasso,

The actual handrankings used are these:

"Push" handrankings:
AA, KK, QQ, JJ, AKs, TT, AKo, AQs, 99, AQo, AJs, 88, AJo, ATs, 77, ATo, 66, A9s, 55, KQs, A8s, A9o, 44, KJs, A7s, KQo, 33, A8o, A5s, A6s, KTs, 22, A4s, QJs, A3s, KJo, A7o, A2s, QTs, JTs, K9s, A5o, A6o, KTo, T9s, J9s, Q9s, A4o, QJo, A3o, 98s, K8s, T8s, A2o, K7s, QTo, JTo, 87s, K6s, J8s, Q8s, 97s, 76s, K5s, K9o,T7s, 86s, 65s, K4s, T9o, J7s, Q6s, Q7s, 96s, K3s, J9o, 54s, Q9o, 75s, Q5s, K2s, T6s, 98o, 85s, J6s, Q4s, K8o, 64s, J5s, T8o, Q3s, 95s, K7o, 87o, 53s, J4s, J8o, K6o, Q2s, 74s, Q8o, T5s, 97o, 76o, J3s, T4s, 43s, K5o, 84s, 63s, J2s, T7o, T3s, 86o, 65o, 94s, K4o,52s, T2s, 93s, J7o, 73s, Q6o, 96o, Q7o, 92s, K3o, 54o, 42s, 75o,62s, 83s, Q5o, T6o, 82s, K2o, 32s, 85o, J6o, 64o, Q4o, 72s, J5o,95o, Q3o, 53o, J4o, 74o, Q2o, T5o, J3o, T4o, 43o, 84o, 63o, J2o,T3o, 94o, 52o, T2o, 93o, 73o, 92o, 42o, 62o, 83o, 82o, 32o, 72o,

"Call" handrankings:
AA, KK, QQ, JJ, TT, AKs, 99, AKo, AQs, AJs, AQo, 88, ATs,AJo, ATo, 77, A9s, KQs, A8s, 66, A9o, KJs, A7s, KQo, KTs, A8o,55, A6s, KJo, A5s, A7o, QJs, A4s, KTo, K9s, 44, A3s, QTs, A2s,A6o, A5o, QJo, K8s, 33, A4o, K9o, JTs, K7s, A3o, Q9s, QTo, A2o,K6s, 22, K5s, K8o, J9s, Q8s, JTo, K4s, K7o, Q9o, T9s, K3s, Q7s,J8s, K2s, K6o, Q6s, T8s, K5o, J9o, Q8o, Q5s, J7s, 98s, K4o, Q4s,T9o, Q3s, K3o, T7s, J8o, Q7o, Q2s, 87s, 97s, J6s, K2o, Q6o, J5s,T6s, T8o, J4s, 76s, Q5o, 86s, 96s, 98o, J7o, J3s, 65s, Q4o, J2s,75s, T5s, 54s, T7o, Q3o, 85s, T4s, 95s, 87o, 97o, J6o, Q2o, T3s,64s, J5o, 74s, T2s, 53s, T6o, 84s, 76o, 94s, J4o, 86o, 96o, 43s,93s, 63s, J3o, 92s, 65o, 73s, 52s, J2o, 83s, 75o, T5o, 54o, 82s,85o, 42s, 95o, T4o, 62s, 32s, 64o, T3o, 72s, 74o, 53o, T2o, 84o,94o, 43o, 93o, 63o, 92o, 73o, 52o, 83o, 82o, 42o, 62o, 32o, 72o,

I did not develop these rankings and, to be honest, I'm not entirely certain where I got them. They likely came out of somebody's U of Alberta thesis paper about finding Nash equilibrium in NL hold'em or some such thing (or possibly the "Mathematics of Poker"... as I write this I do not have my copy with me). I settled on them long ago while experimenting with poker programming and well before I had any concept of "SnG Solver".

The most important criteria for SnG Solver with respect to handrankings is that the matchup EVs are as continuous as possible over a wide variety of situations. This helps keep the math stable when trying to find range equilibria. To this end, these handrankings seem reasonable and have worked pretty well.

In retrospect, I suspect just using Sklansky-Karlson might have worked just as well and having a single ranking would have saved me a lot of programming work vs using separate push/call rankings. Oh well.

So while these suit the purposes of SnG Solver, I have no basis to try to tell you that they're better than any other handranking. But I can tell you that other than for very specific situations, trying to find the "best" handranking is sort of like trying to find the best snowflake... any victory will be fleeting and you'll go crazy in the process.

At the moment, it is not practical to have user customizable handranks... but it has always been my intention to ultimately support completely unrestricted ranges. I have a plan for this, but I am probably not going to get to it anytime soon. On this note, the tentative roadmap for SnG Solver looks something like this:

1.0.x <= bug fixing, better HH support, UI tweaks, performance improvements, etc...
1.1 <= Top-secret, mind-blowing new feature
1.2 <= unrestricted ranges


Anyways, I hope that helped clear things up. I really appreciate the patronage and GL to you and your horses!

I generated these rankings for the holdemresources calculator.

lol... well there you go. Did you publish these in a paper? I've been lookin through my "library" and cant figure out where I got them...

Nah, not in a paper. But they were published on pokerstrategy forums and in some FAQ pdf.

New version is up: 1.0.6. Go get it!

Quite a few goodies in this update...

• Improved threading efficiency/concurrency... this equals a pretty significant performance improvement... anywhere from 20-60% reduction in solve time depending on the game setup and your particular hardware configuration. Systems with 4 or more CPU cores will benefit the most.
• You can now type in a villains range% into an edit box on the range picker dialog.
• Fixed some HH import issues: incorrect seating order on PokerStars HHs, and crashes on iPoker HH import.
• Support for the weird rules on Merge sites when 2 players bust in the same hand. This can be enabled from the Options dialog on the "Rules" page.
• Sometimes if there was an "odd" chip in a tied pot, it would get assigned to the wrong player. This is fixed... although a 1 chip difference usually doesnt affect the results much.
• CPU/GPU system information is displayed on the About dialog
• Some small UI tweaks and other things that probably no one will notice...

This update also includes the foundation for GPU processing support. And about GPU processing, there is some good news and there is some bad news...

The good news is that the potential for increased performance is tremendous... you could easily see a 10x+ speed up for the solves, depending on your particular CPU/GPU combination.

The bad news is that GPU support will be limited to nVidia chipsets only. I have nothing personal/political against ATI's stuff, but I feel the way they have chosen to implement GPGPU programming (via OpenCL) is simply inappropriate for a commercial application. This is a real bummer because they certainly make a lot of good (and popular) hardware.

You can see if your GPU will be supported by SnG Solver by checking the "System Information" area on the "About SnG Solver" dialog".

"CUDA devices" shows the number of devices in your system capable of GPGPU processing. "CUDA compute level" is the version of those devices. SnG Solver will require a CUDA compute level of 2.0 or higher. This is covered by most nVidia devices sold in the last 2 years... all the 400 and 500 series cards.

("CUDA" is the name of nVidia's GPGPU system, FYI)


And there you have it. Go nuts.

Could you go a bit more indepth as to why you won't use OpenCL? It's pretty awesome and both sides support =[

The problem is that the way OpenCL achieves its platform independence is by implementing a "just-in-time" compiler in the driver. This means that you must essentially distribute the GPU program source code along with the application. As you can imagine, thats not something most commercial developers are keen to do...

There are ways to compile a binary from OpenCL ahead of time and distribute that instead, but on the ATI platform, this ends up being a complicated array of device specs without a guarantee of binary compatibility across hardware variations. And that means a lot of extra development and support work.

The nice thing about nVidia/CUDA is that there is a strong guarantee of binary compatibility across an entire generation of hardware. There's even a degree of forward compatibility in their system. With a single binary, I can cover the entire nVidia product line since 2010 (even the mobile stuff) and possibly even their future 600-series stuff thats only now being released.

In other words, ATI/OpenCL is just too much work for a small operation like mine to deal with at this time.

I'll definitely keep an eye out for a way to make it happen... if something changes, or maybe I've overlooked something. But for now, its just not practical.

I've just found and corrected the equilibrium glitch that ginandbread pointed out a few posts ago.

You can get this fix by re-downloading and running the 1.0.6 upgrade installer. I didnt change the version number, but the build # will be 1001 instead of the original 978. You can find the build # on the "About SnG Solver" dialog.

Hi jason,
really nice work you have done here, something I thought about a lot over the last 18 months or so but without the mathematical or programming know how I struggled to make my ideas into anything useful.

I came up with a number of different equity models in this period but the part I always got stuck on was how to assign ranges for the future game simulation part. Page 5 of THIS thread has some of my first thoughts on simulating a few rounds ahead.

Would you mind divulging a little how you come to the ranges for your FGS, is it based on fictitious play/ICM nash ranges or have you found some other way.

Many Thanks,
nibbana

Thanks for pointing out that thread... I just finished reading/skimming... super interesting!

And yes, what I do inside of SnG Solver is very similar to what you suggested. I solve a Nash equilibrium for any node in the game tree where I need get a frequency for a player action.

I really thought some of the posts and info in that thread was amazing. It really captured the issues of tournament chip equity calculation.

In particular, regarding player position as a factor, I think jbpatzer hit the nail on the head when he said (after simulating equity for various game setups):

An equity model can cancel out the variable of position by introducing randomization with respect to that variable... and this works for solving for macroscopic, tournament-wide equity. But, if you are in-the-moment analyzing an individual poker hand, there is no way to Monte Carlo-away the fact that you are UTG, etc...

Also, I thought the observation on page 1 about the relationship between stack size and position is super important... that the EV of position/initiative can change polarity with respect to stack sizes. This is yet another wrinkle that should give pause to anyone trying to come up with a simple linear expression to "adjust" any of the standard ICM models.


As I think about it now, I think we should distinguish that a value for chip equity can be either macroscopic (e.g., applicable when considering an entire MTT) or tactical (applicable to in-the-moment decision making). These are really two different things, and they are not particularly interchangeable... and position is one of primary ingredients in this distinction.

So given that, we could now start binning things up...

Macroscopic TEQ models: Malmuth-Harville, Malmuth-Weitzman, Roberts (new model getting some attention recently), Ferguson's chip diffusion, etc...

Tacical TEQ models: Predictive Simulation (a la SnG Solver)


Heh, yeah, I like that. Tactical chip equity vs. Macro chip equity. I'm going to have to try to work this into the jargon of the poker community.

Thanks for taking the time to reply.

Yea, jb, pzhon & muebarek confused the hell out of and enlightened me in equal measures ! Is that an ICM Nash equilibrium you use then, do you think it's worth looking at M/W or diffusion equilibria too or would the changes in results be negligible?


Yea it does look to me now that the problem can only be truly solved by simulation, that we shouldn't be so worried about compute times and more about accuracy of equity estimation especially given how small the edges are nowadays.

I don't think I can stress enough how glad I am that someone has committed to a project like this, the scope for it is pretty huge imo. Have you given any thought to any of this stuff:

• Whether a Heads Up Push/Fold FGS Nash Equilibrium would look especially different to the Push/Fold ICM Nash Equilibrium ?
• Could Sng Solver utilise HEM in the same way as WizHUD did with Sng Wizard to allow for more efficient/accurate (perhaps automated) estimation of ranges
• As someone already mentioned playing Equity models off against one another to see what edges are like

I could go on but I would guess you have enough to do without fielding these questions !


You may need your own section in the poker dictionary with all your acronyms and jargon

Hello,

I've already tried a few beta versions and those were very helpful but not practical due to no HH import. I see now that you've implemented it and would surely buy the program but I can't import hands from Ongame. Places where the importer stops:
- spaces in nicknames. Very common Ongame so it's annoying to fix all HHs manually, also my own nick has a space so I can import 0 hands without editing
- seats don't necessarily come in succession, for example the HH below with 6,8,9 returns error

Anyway another option which would be way more useful is to add HH importing from HEM hand history viewer. I then would be able to view only my marked hands in HEM. HEM stardadizes imported hands from all the rooms to the same format so you wouldn't even need to add support for all the rooms cause most SNG players use HEM (afaik). The hands would look like this:

***** Hand History for Game 522130334346 ***** (On Game)
Tourney Hand NL Texas Hold'em - Friday, March 02, 12:46:25 ET 2012
Table Table 1 221303343 (Real Money)
Seat 9 is the button
Seat 6: Timosjoek ( $4380.00 USD )
Seat 8: Rolandas M ( $2710.00 USD )
Seat 9: fgjdsq ( $410.00 USD )
Timosjoek posts ante of [$20.00 USD].
Rolandas M posts ante of [$20.00 USD].
fgjdsq posts ante of [$20.00 USD].
Timosjoek posts small blind [$100.00 USD].
Rolandas M posts big blind [$200.00 USD].
** Dealing down cards **
Dealt to Rolandas M [ Th 4s ]
fgjdsq raises [$390.00 USD]
Timosjoek folds
Rolandas M calls [$190.00 USD]
** Dealing Flop ** [ Ad, Ks, Qd ]
** Dealing Turn ** [ 7c ]
** Dealing River ** [ 5s ]
fgjdsq wins $940.00 USD from main pot
Rolandas M shows [Th, 4s ]
fgjdsq shows [Kh, 6s ]

Great work so far, keep it up.

Well, the "leaf" nodes are currently initialized with M-H ICM, but as the game tree is solved, each node's equilibrium is based on progressively "refined" equity approximations. I've tried lots of ways of seeding the leaf nodes. In many cases, the difference between seed algorithms becomes negligible as the simulation depth increases. Part of the continued development for SnG Solver has been in this area... finding the effects of seeding setup and simulation depth on accuracy and performance.

I think when heads up, these become identical... i'm pretty sure this is mathematically true (I cant seem to think clearly about this right now)... but I do know that experimentally, the difference has been zero or nearly zero for every situation I've tested.

I probably could. Opponent modelling is an interesting wrinkle in all this kind of stuff and I've got some ideas about this...

I have actually done some of this (some results are scattered around in various STT posts). I dont have a good set perfectly comparable #s, but the basic jist is this (for short-stacked, 6-max type STTs): PSM (SnG Solver) > M-H ICM > Roberts ICM > M-W ICM > chip EV. At some point, when I've got a complete set of data with high confidence levels, I'll publish some detailed results.

No worries... I'm happy to talk about this stuff

Thanks for the info. Being in the USA I dont have easy access to lots of HHs and sometimes its hard for me to know if my parser is 100% correct. I'll check it out (I recently corrected a "names with spaces" issue for PokerStars HHs too).

Sounds like a good idea. I'll look in to it. I've got HEM, so I do have access to those HHs.

Thanks for the feedback!