by Yogi Rob wrote:FDSaussure wrote:There appears to be significant problems with these statistics. From what I can see the statistics appear to try give your ICM calculated $EV or PP%EV at the end of the hand.
Correct, ICM stats are currently calc'd based on end of hand chip stacks. This might be changed.
This should be changed I think. I'm not sure how you intended people be able to use these stats? what is your end goal to develop here? If this is just the first of many pieces can you paint the picture?
I do understand ICM quite well but am at a loss as to the ptactical application you intended for those new stats. Can you cite a few examples of how you would actually be using these as implemented? (i.e. during/after play and for what purpose)
For practical purposes there is really only 1 ways you could use them as implemented today with no changes that I can see
1) Post-play review. What was my ICM equity before the hand, after the hand, and how much did it change. This could be seen only by looking at the last 2 hands, with prioir being the result of 2 hands ago, after hand being the result of the current hand.
Here's the tool that I know of to be the most popular quick ICM based calculator for push/fold ranges on the web.. I tossed an example in it (see link)
http://www.holdemresources.net/hr/sngs/ ... 7=&s8=&s9=
That link shoots you to his result:
---------------
Level: 100.0/200.0/0.0
Structure: 0.5/0.3/0.2
Players: 3
Runtime: 35ms [300 Iterations]
Player Stack Push% EQPre EQPost EQDiff
BU 2000.0 34.4% 0.4038 0.4104 0.00659
SB 1000.0 84.6% 0.3286 0.329 4.4E-4
BB 500.0 0.2676 0.2606 -0.00703
Explanation:
Stack: Players stack before posting blinds.
Push%: Percentage of hands a player open-pushes.
EQPre: ICM equity before blinds.
EQPost: ICM equity after hand.
EQDiff: ICM equity change during hand.
PU CA OC Range
BU 34.4%, 33+ Ax+ K4s+ K6o+ Q8s+ Q9o+ J9s+ JTo
SB 5.4%, 99+ AJs+ AQo+
BB 1.8%, JJ+
BB 68.6%, 22+ Kx+ Q2s+ Q4o+ J2s+ J6o+ T2s+ T7o+ 93s+ 96o+ 84s+ 86o+ 73s+ 76o 63s+ 65o 53s+ 43s
SB 84.6%, 22+ Tx+ 92s+ 93o+ 82s+ 84o+ 73s+ 75o+ 63s+ 65o 53s+
BB 99.1%, 22+ 4x+ 32s
Explanation:
PU: Pushing Player. Applies when no other player entered the pot yet.
CA: Calling Player. Player pushes after another player (PU) is already in the pot.
OC: OverCalling Player. Player pushes after two other players (PU, CA) are already in the pot.
----------------------
Looking at that lets me really think about what you ought to do here.
1) I think having an ICM value at the start of the hand and one for the end of the hand and one for the delta (or that could be calcd) would be much better. All on one line and you could see the change. That ought to be easy enough.
2) If you want to use this for deal making purposes you need to know the payouts... so you cant use that stat live during play anyway as you don't get it to work live during play since the final payouts aren't loaded yet.
3) This stuff really starts to verge on replicating SNGWiz and like functionality here, but that's ok: (don't think there are Copyright issues here but you'd havew to decide)
a) SNGwiz derives a lot of it's functionality from the fact that it has a default payout structure built in and also has repositories of almost every sng payout structure for the sites sitting in tables. you can pick for a given sng for instance from a zillion options, but the point is you could pick *standard FTP superturbo 9man payout* and it knows what the structure is in %... and along with the buyin - Voila!. Right answer.
build that whole set of tables plus let users enter payout structures of their own and you can really let people analyze what's going on - even before the results are in.
even if yo ujust buld te ability to associate a table to a tny and let people build their own it's a start- over time the standard ones could be downloaded from teh repository as users built them or integrated etc...
b) if you know the payout schedule, then yes, you only need to look at the last hand to figure out how you want to make a deal, except that fails as I need ot know everyone's ICM value to do that. so i think you'd need more to have a deal making module. Well, you would need a *lets make a deal button that popped up wth the ICM value for the remaining players. Now that would be useful. All it needs to know is the payout structure - either from predefined tables, or letting you quick populate a popup window. Since you have the stacks already, just let people fill a payout sched simply, either as % of pool or $ value if you don't have it pre-defined.
http://www.poker-tools-online.com/icm.html is a good example of a tool people use to do this
c) once you have the stacks and payouts like in first example I pasted, you can give the pure ICM p/f ranges as in above. VERY USEFUL STUFF. Very simple stuff too.
if you want to go further, do as SNGwiz does. let people define different shove or calling ranges by player and incorporate those mods in.
d) Now at this point I don't know if this violates TOS everywhere or not but, if you know the payout structure, and you are obviously importing hands, no reason you could not display most recent ICM equity in the HUD for all the players. now that would be the 100% nuts for any SNG reg.
Assuming that does NOT violate TOS...even better would just be a popup that listed all the seat numbers/names and their current stack/ICM value. I know that is ingherently problematic using HH, but why not populate the player HUDS with HH data, but use whatever your Rush technique is to populate that one additional on screen pod, so it gets R/T data?
There is 12 cents worth of my thoughts lol
p.s. put a $ sign on the ICM equity field, a % sign on the % field, and let the user config the number of decimal places of either that they want to see...
![[ img ]](http://s1.directupload.net/images/100507/y7xndh44.jpg){kind=link}