Can anyone recommend a poker hand odds online calculator for calculating ev for starting hands in hold em versus a range of hands, with the ability to account for dead cards? I'm trying to calculate some starting hand values and the effects of various cards being removed from the deck to see its effects on the hands' values.

propokertools.com, pokerstove

I don't know about pokerstove, but propokertools doesn't give exact results. It appears they simulate 600,000 hands when you provide a dead card. I believe this is because they have pre-computed results for a fresh deck, so they don't actually have to do complex calculations. These computations are not trivial. When you calculate the equity of a single hand vs. hand matchup you have to enumerate every possible board, of which there are 48C5 = 1,712,304. If you want to calculate the equity of a single hand vs. a range of any two cards, there are (50C2)*(48C5) = 2,097,572,400 possibilities. If you want to calculate the equity of a range vs. range, it could be even more. Of course, there are ways to reduce the search space, such as recognizing that 5c5s vs. AhKh is the same as 5c5d vs. AsKs, but it's still a lot.

Further, evaluating hands is not as cheap as it seems. A program needs to use a lot of logic to determining the relative value of two hands.

I am working on my own evaluator for another project which I believe will be able to quickly calculate the exact EV of any range vs. range with dead cards.

Of course, if you are okay with approximate results and don't need exact results, the above programs will work. Equilab will also work when you select the Monte Carlo simulation. Equilab can do an exhaustive search, too, but it is very slow when you give it dead cards and a hand vs. range.

Hi, me I use pokercruncher bc I have mac. But I m really not sure also if it takes dead cards into account. For example if I give A5s vs AA AK AQ KK QQ, I m really not sure if the range counts 3 combos of AA or 6.

OP asked about “calculating EV”. Several experienced and very competent posters responded but none noted that the free software programs mentioned (PokerStove, Equilab, ProPoker Tools) calculate equity, not EV. The latter metric involves pot and bet sizes that these programs do not consider as far as I know.

Is this comment somewhat nerdy? Sure. But if we're not precise in terminology we may not be precise in our analysis.

Knowing what the OP wants it for I assumed he was talking about equity. I agree it's important to be precise with terminology.

When I said I am working on a calculator that would be able to calculate the EV of a range vs. range, I did mean that for the game he is interested in. I'm almost done, also; I'm in the optimization stage. Right now it correctly calculates the equity of AA vs. atc in 20 minutes and I'm working on optimizations which will make it orders of magnitude faster, then it's a short step away from being able to calculate EV rather than just all-in equity.

Hello,
(Disclosure: I'm the developer of PokerCruncher.)

Thanks for using PokerCruncher.

Re. your A5s vs AA AK AQ KK QQ example, yes PokerCruncher takes card/range removal effects between the two hands/ranges into account here when calculating equity/odds. Any odds/equity calculation program has to to get the right results.

Re. "dead cards" O.P. may have been talking about something different: not involving range vs. range, but having just one range and marking some of the 52 deck cards as being dead. PokerCruncher has this dead cards feature too.

Regards, -RJ

I have a program which can calculate the exact all-in equity of a pre-flop combo with an arbitrary number of dead cards. One pre-flop combo takes 10 seconds now on my computer (for comparison, equilab can do the same thing, but takes about 1 minute). There are further optimizations I could use to make the all-in equity calculation faster, but I don't care to make them because they won't benefit me (the program isn't made to calculate all-in equity, it's just capable of it with some minor modifications).

If you want to know the equity of some specific combos with some specific dead cards, I can run the calculations for you. The program doesn't have an interface at all right now, though, so I wouldn't be able to give it to you without making a simple one. Right now I'm just hard coding the inputs and re-compiling each time.

I am guilty of doing the same, but damn dude, make some command line args or a conf file or something!

Lol, I'm pretty bad about it. I can partly blame it on inexperience. I am mostly self-taught so I'm still discovering ways like this to make my life easier. To give you an idea, cout is still my main debugging tool.

At least I'm learning to use the built-in debugger of Code::Blocks, and have gotten much better at writing more manageable code and being more organized.

FWIW, I've tested my program against propokertools and am confident that it is perfect without considering dead cards. I wasn't able to test thoroughly with dead cards enabled because of the limitations of propokertools, but my results are most likely accurate since no new code was needed to test dead cards, just a couple extra calls to thoroughly tested existing functions.

Regarding PokerCruncher, does it calculate equity by enumerating all possible outcomes or by running a simulation, and can I see the exact equity? Equilab has the "enumerate all" feature, but AFAIK it doesn't give exact equity, only two decimal places are displayed. Propokertools.com tells you the exact wins/pushes/losses, but it doesn't enumerate all possibilities when using the dead cards feature; it only simulates 600,000 hands.

By the way, it seems the free version of equilab's monte carlo simulation is inaccurate. I tried to calculate the equity of {2c2d, 3c3d, 4c4d, 5c5d} against {random} with dead cards {2h2s}, and the Monte Carlo simulation converges to .5059, while both my program and equilab's "enumerate all" feature give .5063.

(I'm the developer of PokerCruncher.)

PokerCruncher primarily does Monte Carlo simulation. It does do enumeration sometimes, but only in very simple cases e.g. if there are no hand ranges in the scenario and all players' cards and the flop cards are specified. I chose to rely mainly on Monte Carlo simulation because it's a very general/applicable method, and PokerCruncher is a general program e.g. you can have 10 ranges up against each other, dead cards specified, the ranges can have %age weights on some of their cells/hands, etc. Enumerating accurately in such cases may be tricky / very large, so PokerCruncher goes with Monte Carlo simulation.

>>> can I see the exact equity?

PokerCruncher gives equity and stats up to 2 decimal places, or sometimes 3 decimal places. I.e. it gives you 4 significant digits. That's enough accuracy for normal usage/analysis I think. Only if you're doing detailed testing would you want to see more decimal places I would think.

>>> Propokertools.com ... it only simulates 600,000 hands

This seems too low a number to me, for a desktop/web program. I believe even for a basic range vs. hand scenario you need on the order of millions of simulations/hands/trials to converge on a very-accurate answer. For an accurate-enough answer, prob. 600k trials is enough. PokerCruncher (the Mac-Expert version) does about 1 million trials/sec (and my Mac is a few years old), so converges pretty accurately within a few seconds. There's also an Infinite setting that lets you run the simulation indefinitely.

I haven't tried this in Equilab so can't speak about that program, but yes if you're doing at least many millions of Monte Carlo simulations then any program should converge on 50.63% here. PokerCruncher does, output below (101 million trials in about 55 sec. on my 2014 MacBook Pro):

=====
PokerCruncher-Expert-Mac V.11.5.2

(Equity, Win, Tie)
Player 1: 50.63% 49.74% 1.775% {5d5c, 4d4c, 3d3c, 2d2c}
Player 2: 49.37% 48.49% 1.775% [??]

Board: [? ? ? ? ?]
Deal To: River
Dead Cards: {2s 2h}

Monte Carlo Simulation: 101004891 trials

Notes:

=====

Thanks, I was curious if PokerCruncher would have allowed me to test my program. It seems it won't, but it sounds like a great program for a poker player.

I suppose it's no surprise that you use the simulation approach. It's much more versatile when exhaustive approaches simply take too long for more than two players. My approach is probably a bit different than yours since I calculate hand vs. range equity at the leaf nodes rather than evaluate individual hand vs. hand. My program does about 200,000 hand vs. range evaluations per second on a few years old, cheap laptop.

At the leaf I hash the boardState to get a key to a lookup table which provides a range of hands that the player's holding beats and pushes with on the given board. The data is stored such that each bit set corresponds to a win/push. I can mask this with another object representing villain's range, and the number of bits set in the result is the number of wins/pushes Hero's hand has against villain's range on that runout. I used this method because it's easy to mask dead cards, also. Not sure if this makes sense but I thought it might be interesting.

Yes, 600K seems light.

Everybody probably knows the formula for standard error of a proportion (a poker player's equity in a hand can be thought of as a proportion). I learned a simple rule of thumb years ago to determine how many samples are required to get a desired "accuracy" in a proportion near 50%.

Using a desired accuracy "threshold" to be 2 standard errors (in either direction), then:
- Within 1% requires 10,000 samples
- Within 0.1% requires 1,000,000 samples
- Within 0.01% requires 100,000,000 samples

I learned this many moons ago and my memory ain't what it once was, so somebody should probably confirm/deny this.

For a binomial measure such as VPIP or 3-bet percentage or win probability, to be C% confident that the sample mean deviates +- d percentage points from the true mean when the true mean is believed to be P, the required sample size using a normal approximation for the binomial is

N = (Zc^2)*P*(1-P) / d^2,

where Zc is the standardized normal deviate corresponding to a C% confidence interval. For 80%, Z = 1.28; 90%, Z=1.645; 95%, Z = 1.96.

Using a Z of 2 and P = 0.5, whosnext values are right on.

Example: d= 1%. N= (2^2)*0.5*(1-0.5)/(0.01^2) = 1/.0001 =10,000

Re. posts #15, #16 above ...
Thanks for giving the theory behind the convergence of Monte Carlo simulation guys.

After running prob. thousands of simulations in the PokerCruncher app over the years, the estimates from the theory are pretty much exactly what I see in the program. E.g. when I gave the results from the program above in post #13, I intuitively ran 100 million trials to get to the two decimal places accuracy of the 50.63% result.

The theory also agrees with my observation/intuition for one decimal place accuracy: millions of trials needed.

Of course for real life hand analysis, we don't need results this accurate. An error margin of one-tenth or two-tenths of a percent is prob. OK (i.e. doing less than a million Monte Carlo simulation trials).

That's correct, there is no free version of PokerCruncher-Expert-Mac. There is a free iPhone version of PokerCruncher in the iOS app store, but it's limited features, no hand ranges.

Re. your algorithm, thanks for describing, it sounds pretty interesting. But I must admit I don't think I get it yet even after reading it a few times. That's OK, as this thread prob. isn't the place to discuss our algorithms in detail anyway.

>>> My approach is probably a bit different than yours since I calculate hand vs. range equity at the leaf nodes ...

If you can scale up your algorithm from "hand vs. range" to a maximum general setup like I described before (e.g. 10 ranges up against each other, dead cards, %age weights in the ranges's cells, etc.) then (future) kudos to you : ). That was a primary goal in PokerCruncher, to be as general a program as possible.

So the approach in PokerCruncher is simpler wrt the engine's underlying algorithm. At the core it's a simple/lightweight algorithm that relies mainly on Monte Carlo simulation. There are some optimizations in place that help give the 1+ million / sec. Monte Carlo trials, but even those are lightweight (e.g. no huge lookup tables that can explode the size of the program). The advantage is that this simpler approach can be scaled up to fully general setups e.g. 10 ranges, and lets us calculate not just the Equity stat (it's easy to optimize just for this stat) but also the several dozen additional Deal-To-Flop/Turn stats PokerCruncher has (in an acceptably fast way). Anyway, prob. out of scope to discuss more here.

I didn't articulate very well. I'll try to explain better in a PM. Some of the things I did were for a very specific application without the intention to write a more general program that can do the things PokerCruncher can do. I actually haven't even thought about how my algorithm will scale to more than two players, but if it can maybe I'll design my own general equity calculator.

My first thoughts are that my algorithm can't effectively scale to more than two players. At the leaf I can calculate the exact equity of one player against each of the others individually, but the probability of beating each other player is not independent because of card removal, so the probability of beating all other players is not trivial. The same method will scale very badly with more than two players.