The normal exact formula for computing equity P after the flop with 2 cards to come given x outs and 47 unseen cards is:

P_x = (93 - x)*x/21.62

I came up with a recursive formula that computes the next value if you know the previous 2 values i.e. P_z is computed given P_x and P_y:

P_z ≈ P_y - P_x + P_y - .09

So if you know that P₈ ≈ 31.45 and P₉ ≈ 34.97, then:

P₁₀ ≈ 34.97 - 31.45 + 34.97 - .09 ≈ 38.40

Which is off by less 0.01%

If you continue the recursion to compute successive values, the error accumulates and it becomes less and less accurate. Beginning with P₀ = 0 and P₁ ≈ 4.26, will produce the following results:
If you replace the approximate .09 constant with the more accurate approximate constant .0925, then you get the following:
Now we are accurate to within 0.1%. Not bad for just a couple of additions and a couple of subtractions for each iteration.

Another way of reducing the error is by memorizing just 2 or 3 key pairs of values, so that you are not extrapolating too far.

A nice property of the formula is that it can be used to go backward too. Just swap P_x with P_z as follows:

P_x ≈ P_y - P_z + P_y - .09

For example, with P₈ ≈ 31.45 and P₉ ≈ 34.97, we can compute:

P₇ ≈ 31.45 - 34.97 + 31.45 - .09 ≈ 27.84

The normal exact formula gives the same result when rounded to 2 decimal places. By going both forward and backward and not just forward, how far you need to extrapolate gets cut in half producing even more accuracy.

Using all the tricks, you can get quite good results using numbers accurate to a tenth of a percent instead of working with numbers accurate to a hundreth of a percent.

BTW, even though it is presented as an approximation, it can be made to be exact by starting with exact values and replacing the approximate constant .0925 with the exact 1/10.81. Exact in theory at least. In practice, YMMV.

This is something I came up with just today. I thought I'd post it in case anyone might interested in fiddling around with it. Despite my original intent, I don't think I'll be using this when I play poker. The more usual approximations are good enough and I'm used to using them.

This is probably more simply stated as
Pz ≈ 2*Py - Px- .09

But my main question is... what would you use this for? It's not easier in a real-time estimating context and it's not easier or better offline with a calculator or a program, so...

One of my pet projects is figuring out how to calculate HU poker equities in my head accurately to the nearest half of a percent after the flop. This is a project I already completed by other means, but I still revisit the issue from time to time. It's a Mount Everest type of thing. I do it, because it's there. And along the way I learned a lot of interesting math stuff.

As for practical value, this type of idea can be generalized for any nth degree polynomial and used as a speed optimization in certain programming contexts. With a little modification, you can replace the computing of n multiplications and n additions used to evaluate a polynomial within a loop with just n additions. But this is off-topic for this forum.

OK, that's fine. As I've often stated this forum is about theory. I was just wondering if there was some application I'd missed.

The N adds instead of N adds and N multiplications is interesting but I think it would only be at the extreme limits that it would really be that helpful. Computers multiply pretty good, and the table only needs to be generated once.

It looks like the value in the denominator should be 2162 instead of 21,62. http://en.wikipedia.org/wiki/Poker_p....E2.80.93_outs.

Out of curiosity did you use Eureqa for this project?
I was thinking you could do this by feeding Eureqa with a series of values taken from the real formula and have it figure out an approximation using as building blocks just additions and subtractions.

Does your method allow you to approximate equities in your head with that accuracy and speed so it can be used at the tables?

21.62 is used instead of 2162 merely because it generates numbers in percent i.e. 0 to 100 instead of probabilities in the range 0 to 1.

I derived this algebraically and tested with Python. I did not use Eureqa. At it's basis, it is an exact method as noted in my OP.

In my latest version, I've adapted it to work as a binary search with the following:

P_y ≈ (P_x + P_z )/2 + K_i

You start with the probabilities for 0 outs and 16 outs, which is 0.0% and 57.0% respectively when rounding to the nearest 0.1%. The K_i begins with the value 3.0 and each successive iteration drops it down to 0.7, 0.2, then 0.0. Using this scheme produces the following results when working to an accuracy of 0.1%:
Which is quite good. I figured out that if you memorize the ones for 0,4,8,12,16 outs, you average 1.25 iterations of the algorithm doing at most 2 iterations. This assumes each value is equally likely.

I've tested it out, by carrying it out in my head and it is not difficult at all to do. In it's current form, you could use it at the tables, but it is not worth it. You don't really need that much accuracy. I've only produced this to satisfy my curiosity. I will not be using it while playing poker.

If you want it to produce exact results, the sequence of K_i begins with 32/10.81 = 2.9602220166512487 and is reduced with each iteration by dividing it by 4. Also start with an exact value for 16 outs , which is 1232/21.62 = 56.98427382053654 instead of 57.0.

What is the point of all this?

You have F(x)=a*x^2+b*x+c

and you are basically doing what evaluating F(x+2) in terms of F(x+1) and F(x)?

Obviously F(x+2)=a*(x+2)^2+b*(x+2)+c =a((x+1)^2+2(x+1)+1)+b(x+1)+b+c=
=a*(x+1)^2+b*(x+1)+c+2*a*(x+1)+a+b=F(x+1)+2*a*(x+1 )+a+b

F(x+2)=F(x+1)+2*a*(x+1)+a+b and

F(x+1)=F(x)+2*a*x+a+b

(we could have simply written F(x+1) in terms of F(x) and avoided the 2 steps process above anyway, its easier this way )

so subtraction by parts;

F(x+2)=2*F(x+1)-F(x)+2*a.

That holds for any quadratic F(x) but why is that result useful in anything?


Sorry not intending to be rude or anything just dont see what the purpose is here of something that is probably important in numerical differential equation solutions etc (you know derivatives to differences etc).

Here you have a simple problem. You know the solution directly why bother with recursive expressions?

I believe I answered this more than once already. I'm basically doing it for kicks. I'm trying to solve the hypothetical goal of being able to accurately calculate these values in the easiest way possible without benefit of pencil & paper, calculator or computer program. And as I've said many times before, I would not use this at the table. In any case, this is a theory forum. Things do not necessarily have to be useful for anything.

You are right about this being workable for any quadratic. Similar methods are possible for any polynomial and not just quadratics. It can also be "inverted" to obtain roots to polynomials as well.

I was done with posting on this topic due to lack of interest, but then erdnase17 expressed some interest, so I supplied a bit more information. I'm not trying to sell the idea on anyone. Like I said many times before, I would not use it in a game.