Could you please add a chart so that we can click on it to assgin opponent's hand range
just like the one when we select our hand.
It will be much more convenient if we want to customize opponent's hand ranges.

Thanks.

Is this a WPF app? VS2010? C#?
Great work Q...

Hangson : sure it is going to be added among first new features in nearest time, my goal is to create very easy control to input user range. But its beta now, and you already can manually edit with keyboard so its out, but range editor will be added soon.

TBard: Silverlight is a subset of WPF. Vs2010 C# , WPF, Silverlight 4.0 currently.

is this mac only ?

Its Mac too, supports both Windows and Mac. Made myself unclear there, thats unfortunate.

I dont think there is any soft available from browser that only supports Mac or is it?

paul rizzo posted a hand in another thread where he was wondering whether SngWizard and sng solver compute ICM correctly for situation where

Stacks are 3000,3000,3000 Payout is 70%/30% (6max) Blinds (300,150)
we are on BB with K5s
and SB pushes 100%

SngWizard gives our call a +0.9%, Sng Solver thinks its +5.5% (seriously?) which is incorrect, so ICMIZER is really a first program that computes ICM correctly in history and sng_jason steal attempt failed.

In reality ICMIZER can show that its even more and both programs are computing incorrectly : www.tenbb.com/pokericm/icmizer/nBcu Open this link and just click [Compute K5s], you can see that its actually +1.1% because split is also a good outcome for us and we dont bubble that often. If your interested hover over (i) icon to see our EV after tie and tie probability vs random range.

I hope this clearly shows the benefits of my calculator and influence of tie on real outcome in daily poker hands, not just extreme cases.
It will affect all your call decisions BvB greatly (and generall call situations), also this situation is final and outcome can be calculated to with 100% certainty, no overcalls can happen, etc,

Your program is great so far especially for bvb spots and really cool for resteals. The only thing is that it doesn't consider overcalls. This is obviously super important in a lot of spots especially when shoving a short stack shoving into a few or several players. It seems to me that in a lot of spots we would be better off without the tie possibility calculation and with atleast an attempt to handle the overcalls.

Basically im saying that the program fails in certain spots but is great and super easy to use in other spots. Nonetheless cool program that I look forward to using more in the future.

Indeed paul rizzo. I clearly say that it doesn't consider overcalls anyhow currently. Others do, but meanwhile they cannot compute EV correctly for simple BvB situations. I also say that computations are exact and correct, for situations which it considers (all 2 way action situations).

It means that its 100% efficient when we are analyzing HU SNGs, or SB VS BB spots in any kind of SNG or MTT regardless of total player count on table. The more players can act during a hand except us and our opponent the bigger mistake ICMIZER makes however.

But like I say computing 3 way allins correctly is very difficult, it requires a lot of computation power and even time. Currently there are none programs that perform that correctly. I am planning to work on that heavily if ICMIZER becomes somewhat popular and I feel that its going to become commercial.

Why is the equity wrong in this?

You probably need to go to sng wizard with those questions. Ill give you another one though: when does wizard computes SOMETHING correctly, and it can be proven? Except HU.

As you can see ICMIZER is providing a icm calculation that is equal to AA vs AA case in same situation:

He normally pipes up in threads like this but no sign of him yet :/

Not much to say I guess.

Q,

I'll be interested to hear from the SNG Wizard guy but I'd be shocked if he wasn't aware of the tie thing. I think the hand range problem it has is also because of speed issues. I'm guessing he decided to pass on those things and include 3-way allins. It's not perfect, but it's "approximate correctness" is probably much more acceptable in most situations than you're letting on. But I understand you are trying to sell something here.

I'm excited about the possibilities of your program, but if you don't yet have 3-way allins or "hero folds" situations then yours is incomplete too. Figure out a way to solve those things with your accurate calculations, then you'll really have something.

Why do i get the same Results with icmizer and Sngwiz when i analyze Sb vs BB shoves? Should be different or not?

Hey Cpt.Hero. I am thinking your analyzing headsup, in that case tie odds actually don't matter and results will be the same. If you analyze 3 way bubble of 6 max sng SB vs BB youll notice different results instantly.

I am not sure about your shocked part, even if he is or was aware of that bug, it just means he was claiming program was doing something for years, which it wasn't doing, which I think isn't good.

I am trying to create a good software piece that is usable, lightweight (currently download is 1mb compared to any other similar program thats nothing), easily available and helpful. As for selling I believe a lot needs to be added before I even think about selling my program.

I find limitations of wizard for many situations not appropriate. I am also kind of math guy who likes equations, and correctness. Currently ICMIZER provides correct results given its limitations. SngWizard on other hand does not, results are incorrect given its limitations.

Consider headsup SNG for example, or general headsup sitatuation,(or BvB more generally) inability to edit range in wizard is huge limitation here. Of course since I clearly say that currently 3 way allins arent supported you can't really blame my program for not doing 3 way allins (I hope). In a big variety of situations its more useful and correct than wizard already, available freely to anybody. I also plan to leave some default daily abilities freely always, even if we get to paid version at some point.

Since you invited me…

You claim the Wizard is “wrong” for ignoring ties and your program is “right” even though it ignores overcalls. For most hands, I suspect ignoring overcalls is a bigger error than ignoring ties.

That said, you have done some good work here. You have motivated me to investigate this tie thingy.

Hey, please do. I say that its "right" given its limitations, without considering overcalls , it is right technically, for situations it considers. (it can be checked by doing fairly simple calculations by hand if we edit ranges so they don't consist too many hands)

Thanks for appreciation

As for overcalls - there are many ways to implement support for them, but currently ICMIZER is in public free beta because I believe it is already useful for tournament players, and I can continue to develop meanwhile.

Just fwiw, my implementation has been online for more than a year (and a more basic one since 2007). Both versions are handling split pots just fine, and also allow 3-way pots / overcalls.

http://www.holdemresources.net/hr/beta/calculator.html

For the K5s example:
http://www.holdemresources.net/hr/be...&sb=150&ante=0

Set the SB range to 100% and you get for BB calling K5s, EVDiff%=1.101. (This is the same result you get, correct?)

Also, Jason explained in the SnG Solver thread that the +5.5% are relative to the players existing equity, while most other software shows the equity change as absolute price pool %.

Change the name and I'm on board!

Seriously though, a few thoughts...

1) How can you exactly compare your results to SNGwiz if you arent also computing Hero fold correctly? It looks like you made the overcall ranges in your Wiz comparisons to be as small as possible, but they aren't 0. If they are 0 wouldn't this make the EV of the call go up a bit in the AK/AJ hands? I believe so (but no idea how much).

2) I have been a vocal hater of SNGwiz programmed calling ranges. It is by far one of their worst features and automatically one of your best features NOT to have. However, I think adding Herofold equity calcs should be your 1st priority.

3) I could live without 3way allin calcs personally, since theyre rare enough. Although if you add them eventually, you would be unstoppable!

Love the flexibility between pc/mac and sharing links to hands etc. Great work!

Hey braminc thanks! as for

1) I set overcall to AA everywhere, you can do that in wiz. Since in most my examples we hold an ace or a couple of them it should show that overcall is super rare. Also in example with AA vs AA and overcalls on AA it means that overcall is 0%. Comparison is fairly ok. If however someone needs more proof, he could analyze bubble situations where we are pushed at from SB. There are no overcalls possible and results will be very different with wizard. Perhaps I should have included those examples in my examples. I might replace them in help on site I guess. Its clearly my mistake to present it in such a way that everyone is thinking about possible overcalls..

2) maybe you are right , but there are some basic features missing, then ill go for herofold since its easier than 3 way allins , especially for call mode.

3) eventually I will

As for handrange input my next release will have a better range input control , with cards shown (more like pokerstove and hand selector in icmizer currently) because currently as I found out few people are figuring out they can edit range by hand.

Hey plexiq , can you show me an example where we are pushed by 100% range and you show equity for tie , fold and call in your program? (situation from this link :www.tenbb.com/pokericm/icmizer/nBcu)

I might be dumb but I cannot see how can I set sb on 100% to see EV for calling K5s in your program.

As for 5.5% etc I would like to not mention solver in this thread, but first of all its impossible to compare it to other programs currently, and another thing new bugs are found there (saw one found yesterday) which means it isnt computing correctly. No computational bugs are found in ICMIZER on other hand.

You mean other than to try and suggest that its somehow flawed and that your program is perfect. Countdown in 3... 2... 1...

Seriously. Please stop.

Creating a working program that computes ICM correctly isn't an easy task.

I am saying that I am already computing correctly first and I really am. Also I am computing correctly ICM, not some other kind of equity or numbers, and provide results in typical ICM form that was out for ages. You keep arguing about ICM usefullness, well its your call. I am saying that I am computing correctly ICM, not something else.

If HM resources is also computing that like I do, (but I currently cannot see what can I be missing, I cannot edit SB range in that sample) it could mean they were first. However they don't display EV tie and EV win and EV lose anywhere so I am really not sure.. Also if they did that differently than wizard for a year, why didn't they say about it? Also they are running some kind of iterations which to me might mean that there is some kind of approximation going on, ICMIZER is giving exact results, but I am not sure what those iterations really mean.

I was told not to discuss other ICM tools in my threads or present ICMIZER and compare it in your thread by moderators.
Again you are NOT computing ICM equity at all (that 5.5% thingie) so what are you arguing about (regarding my "computes icm correctly first" statement)? Your welcome to answer in pms.

for your example with blinds 20/10
HoldemResources.net Results
blinds 300/150
HoldemResources.net Results

- select "PU SB"
- click display range
- edit to 100%, lock, apply range.
- recalc nash