When are you planning to enable this feature ?

Right now, I am not sure. Since my initial CUDA development, I've made some big changes to the SnG Solver engine and to my ideas/goals for the future. Because of this, I've held off on more CUDA work until some of these other things get sorted out.

But I can tell you that GPU/CUDA computing is *definitely* going to be a part of SnG Solver's future. nVidia recently released their new generation of GPUs code named "Kepler" and a new CUDA language spec... and I was very pleased by the direction they're going. The architecture seems to be very well suited to the problem space that I plan to have SnG Solver head into.

Hi Jason,
Great software I really like the PSM model since obviously the traditional ICM calculators have glaring flaws. Two questions regarding Fifty 50s in this respect:
1.Does the Solver calculate the extra EV from action behind Hero if he folds in terms of EqF of Hero stack. Ex:Hero folds on the bubble and two equal stacks get it in and one is eliminated. In this case the value of Hero stack increases enormously in the Fifties since 50% of prize pool is distributed to top 5 finishes.
1.1 If yes does it calculate this extra Equity for the next round as well discounting its EV for the current round.
2.If two equal stacks are on the BTN and UTG does the Solver calculate the difference of their EqF value for just this and the next future round or have you developed an algorithm to account for the extra compound EV the BTN stack has cumulative for each spot until UTG?
Thx in advance for your response and for the great support you provide to us all.
Rds
Chav

Your software gives different ranges than HoldemResources Calculator's PSM model for Stars' hyper-turbo satellites (6-max, 50/50 payment for top 2, 500 stack 25/50/10 blinds). Shouldn't they both give the same results if they are based on the same model? How can I get more accurate results?

Yes and yes. Because of the "simulation" aspect of the algorithm, any effects on EV due to possible future stack distribution are going to get accounted for... even those that result from other players actions.

The current version limits the simulation to one future round. The next update will allow the users to increase the total simulation depth. That said, the effects of this are usually less than you might think... unless there is a stack on the edge of hitting the "danger zone", the effects of more future rounds tends to diminish very quickly.

I have no idea about the veracity or completeness of anybody's PSM implementation other than my own. I have spent no time trying to compare results or anything like that, so I cant comment on the state of its implementation. While I have described the PSM algorithm in general in these forums and elsewhere, I have yet to provide a formal, detailed description of how its implemented.

As far as I'm concerned, SnG Solver *is* PSM... and that is certainly my official position.

Now that said (and in the interest of not wanting to appear unresponsive ), I will note that there is quite a lot of potential wiggle-room in the PSM algorithm. This is because of the "P" in PSM... the predictive part.

PSM assumes that future players actions are made according to Nash equilibrium strategies... the problem is that since exact Nash equilibrium strategies are never available, an implementation must rely on approximate Nash strategies... and as soon as you start introducing approximations, you open the door to differences between otherwise identical implementations.

The reality of algorithms that can approximate Nash strategies in a timely matter is that they are very imperfect... very prone to numerical instability and getting an equilibrium to settle can require a lot of mathematical shenanigans. So really, I would be very surprised to see two independently developed PSM implementations give exactly the same results.


Accuracy? Well, if you mean the most accurate PSM implementation, then of course by definition its SnG Solver ... if you mean more "accurate" equities or ranges... well... thats tricky and is sort of like asking who can draw the most accurate unicorn (assuming for the sake of argument that unicorns exist, its just that no one has ever seen one). Without the real thing to compare against, how could we say?

It is possible to make *some* rough judgements...

We know that a unicorn must have a horn and that it probably attracts rainbows... so I guess we can say that a PSM unicorn drawing is more accurate than an ICM unicorn drawing.

Similarly, we can know that a PSM-Nash-approximate strategy has an advantage over ICM-Nash-approximate strategy:


But without an actual Nash strategy or true $EV stack values to compare against, its hard to really say more. Anything else is probably, at best, speculation.


If one model says the BTN should push 24% and another says push 27%, I would advise against obsessing about this kind of difference. It is unlikely to improve your actual poker game.

PSM is meant to plug some of the giant holes that exist in equity models like ICM, but better chip equity estimation is only a part of developing better tournament poker strategies.

Without giving anything away (since clearly, things I talk about have a way of ending up in other peoples programs ), I will say that I believe improving chipEV to $EV estimation is no longer the weakest link in tournament strategy analysis. There are bigger gains to be had in other areas... and this is where SnG Solver will be headed.

Thx Jason,
So if I understand it correctly the PSM model estimates possible developments on the next round based on Nash Eqlbrm strategic interactions b/n all the players and then accounts for that next round extra EV by applying it to the current round`s value of Hero Stack(Equity of fold).
1.Is this correct?
Sounds a lot like the DCF(discount cash flow) model in finance where you take all future expected cash flows of a given asset and discount them back to the present(given risk adjusted rate of return) to determine the Asset`s current value(price).
I like this analogy but if true how about the SNG Solver`s equivalent of rate of return.I think SNGWIZ uses the edge function for this but i don`t see it with the Solver.
2.Do you have similar function?
Thx in advance

Often the program will tell me that elapsed solve time is somewhere between 0:01 and 0:06 when in fact I have been unable to use the program for up to 0:30 possibly longer. Also is there a way to include times where a villain that acts before me has raised some amount but is not all-in?

Basically yes... by considering the future rounds you are able to get a better estimation of the consequences for actions on the current round.

I'm not really familiar with DCF, so I'm not completely sure the analogy holds. I would think that calculated $EV values *are* the return of the function.

The "edge" in a program like sngwiz is only there to band-aid over the fact that the ICM model is so weak... to make up for thing like the lack of ability to account for impending blinds. The problem then with an "edge" is how do you set it correctly? Its completely arbitrary and has no mathematical foundation. Any program that needs an "edge" is basically telling you "i dont know".

SnG Solver's PSM model is much more complete and does not need an edge to give satisfactory results. So there is no "edge" in SnG Solver.

Can you tell me what kind of CPU you have in your system? And how much RAM?

Also, before the solve is complete, does the "ETA" display reasonable values? Or is it off too?


Not yet... but I am working on including support for this kind of situation...

I think one of the biggest shortfalls of traditional ICM models is miscalculation of stack equity(repped as Eq of fold).The Solver is way better in that respect cause it accounts for future round EV(+/-) discounting it from/to current stack value to get to a true equity of fold.
However to properly account for that you need some sort of discount rate(like in finance) which to use to discount your future stack value to present and compare that to your current stack value to determine the EV of your current decision.That is how i understand the 'edge' function:what kind of minimum pos.EV value i am willing to accept in order to risk the future EV expectations of my current stack.
I think you can reasonably estimate that edge by simply subtracting from the Eq of fold of the PSM model the EqF as given by the traditional iCM calcs thus getting the future expected EV as the difference=edge.
What do you think about this?

Well, I suppose you could arrive at an "edge" correction for ICM by using PSM as a benchmark... but what would be the point of that when you've already got the PSM result?

Two questions/bug reports:
*) When I run the program, it says that I have version 1.0.9, but the current version is 1.0.90 and advises to download it. Is it intended?

*) How come that equilibrium range and the suggested range are completely different (it happens both with PSM and without)? If I haven't changed the calling ranges, aren't they assumed to be equilibrium calling ranges?

Hmm... thats pretty strange. The reported version should be 1.0.9, not 90. I'll look into what might be causing this. What language/country code is your Windows set to?


The recommended Hero range is the best-response strategy to the ranges of the opponents and is completely unrestricted with respect to hand selection. The ranges in the equilibrium strategy table are approximations of a Nash equilibrium strategy that are based on a fixed, linear handranking. I realize this distinction can lead to some confusion. I'm working on a soon-to-be-released update that will normalize and clarify things quite a bit.

I'm using Windows XP, it's in English. In Regional Options the format is set to Latvian and the decimal seperator is "." and no. of digits after decimal is 2. However changing it doesn't seem to change the behaviour of the program.

Ok, got it. Just to clarify - the handranking for push is different from handranking for call? And the handranking for overcall is the same as for call? And opponents' ranges can be set only according to these handrankings?

Okay, thanks.

I just made a change to the version server code that might clear this up. The next time you "check for updates", let me know if its sorted.

Yes, yes, and yes. And like I mentioned, in the near future this will all become academic with the changeover to unrestricted ranges for all positions.

Hi!

When I try to import or copy/paste Ongame hand history to Solver I get this error:
"Cant find data/time line"
Any idea what is the problem?

Hi Pl4gue1,

Basically, SnG Solver is getting confused trying to read your HH... its expecting a certain line to be in the header and cant find it.

If you can send me the offending HH (email to support@sngsolver.com) or even just paste it into this thread, I should be able to figure out whats going wrong and fix it.

Can you estimate when's that big update gonna come?

Hy!
All of my HH-s got this problem
Here is my sample HH:

***** Hand History for Game 525164825535 ***** (On Game)
Tourney Hand NL Texas Hold'em - Tuesday, June 26, 09:50:55 ET 2012
Table Table 1 251648255 (Real Money)
Seat 8 is the button
Seat 1: marekk3555 ( $2550.00 USD )
Seat 2: strangel11 ( $3690.00 USD )
Seat 6: 4TD_sg ( $6330.00 USD )
Seat 8: _Pl4gue_ ( $2430.00 USD )
marekk3555 posts ante of [$60.00 USD].
strangel11 posts ante of [$60.00 USD].
4TD_sg posts ante of [$60.00 USD].
_Pl4gue_ posts ante of [$60.00 USD].
marekk3555 posts small blind [$300.00 USD].
strangel11 posts big blind [$600.00 USD].
** Dealing down cards **
Dealt to _Pl4gue_ [ 6d 6c ]
4TD_sg folds
_Pl4gue_ raises [$2370.00 USD]
marekk3555 calls [$2070.00 USD]
strangel11 folds
** Dealing Flop ** [ Ac, 2d, Kh ]
** Dealing Turn ** [ Jd ]
** Dealing River ** [ Qh ]
marekk3555 wins $5580.00 USD from main pot
marekk3555 shows [3h, As ]
_Pl4gue_ shows [6d, 6c ]

How about a medium sized update right now?

1.0.10 is out! A few goodies in this one...

- Added options to control PSM simulation depth.
- Up to 2 computers can now be activated from a single license key.
- Added 2-sigma band display on EV-RMSD graph.
- Added options panel to control "Brazil band" (EV-RMSD) display
- Hands in EV graph now sorted by EV
- Game menu actions now automatically trigger "Edit Mode"
- Ctrl+V will paste HH directly into edit panel from clipboard
- Ctrl+Shift+V will automatically paste and solve HH from clipboard
- Added support for Holdem Manager "Hand History Viewer" hand histories
- Some performance enhancements for multi-core CPUs
- Hotkeys now correctly disabled when sub-dialog displayed


I know a lot of you have been looking forward to being able increase the simulation depth for the PSM... which you can do now, but you must enable it first from the "options" dialog.

I've talked before about my reluctance to introduce new features that can complicate the interpretation of the results (which this definitely can do). This is why this feature is not enabled by default.

Beyond a depth of "1", there are two modes for each additional level of depth... "complete" and "quick". Complete is exactly what it sounds like, it exhaustively includes the entire game tree in the analysis. "Quick" attempts to dynamically prune parts of the game tree that are less likely to actually affect the results. "Quick" does a very good job at getting 99% of the accuracy for only a fraction of the processing time and is highly recommended. The only catch is that right now, the "ETA" display doesnt work very well with the quick modes... I should have this fixed pretty soon.

I'll be spending some time now to get the user's guide back in sync with the actual program... I realize there's been quite a few big changes that arent reflected in the users guide right now.

Enjoy!

It looks like this HH came from the Holdem Manager hand history viewer, right?

The good news is that, as of the latest version (1.0.10... see my post above ), these are now supported!

Very nice, you're now 3 steps ahead of everybody else.

Thx, its perfect!

Hi. Since its support thread didnt search for it. But why is there 13euro tax if I pay with Paypal ? anyway to handle this.
So Id pay more than others

Thanks