I can't even think of how that could possibly happen. What browser/version are you using?

Windows XP SP3 and Firefox/3.5.7

Details from the Firefox Help -> About option:

Thanks. I have been able to reproduce it now. I should be able to get it fixed tomorrow or later tonight.

This is nice. Have you considered contributing it back to pokersource?

Wow. Haven't seen this error for a while:

This was an O8 simulation with board cards of

2h2d9c

and a hand of:

KhJd7d2c

against eight random hands, each one specified by

****



I also continue to have problems with some simulations not finishing at all, or with interim results being posted.

I *do* have the following options set in Firefox:

if that makes any difference.

The "Too many duplicated trials" error seems to be dependent on the number of random hands *combined* with board cards during O8 simulations.

I had originally reported the problem occurring without any board cards being given, just one specific hand against other random hands. Whatever fix you applied resulted in that problem going away.

If I do the simulation with specific board cards (eg., 2h2d9c) and one specific hand against five random hands (Player 1 being KhJd7d2c, for example, and Player 2 through Player 6 being just ****), then the calculation completes. But if I add just one extra player (for 7 players total), the calculation does not want to complete. When I add an 8th player, I get the "duplicated hands" error again. And as reported above, the same thing happens with 9 players (one hand specified, and the other eight just ****).

Note: If I do *not* specify any board cards, I can do simulations of one specific hand against ten opponents (11 players total) with random hands that are ****.

I hope that helps you narrow things down.

Yes I will definitely consider this if I can find some time to clean up and document the code.

Good stuff. Thanks for the detailed report, should be enough to allow me to kill it for good.

I have not been able to reproduce the interim results being shown again on my own. Not sure if this could be causing a problem or not. FWIW there is a request sent to the server every second to check on the status of the calc. I will ook into this further.

I have some performance improvements I am going to make that should speed up the hand range generation part of the calculation significantly and hope that will eliminate some of those irregularities you are seeing since (correct me if I am wrong) all of the problems seem to occur when doing calculations that take more than a few seconds. I suspect part of the problem is being caused by some timeouts occuring either on your end or my servers.

BTW my computers power supply gave up the ghost yesterday and it is going to be a couple of days before the new one is delivered and I am back in action .

With respect to Omaha, one thing you might do is limit the hand ranges based on known cards, either in the test hand or on the board. For example, if I do a simulation in O8 with AcAd2c3d versus nine random hands, then clearly each random hand does *not* consist of the entire universe of C(52,4) = 270725 starting hands (as shown in the table below).


Omaha Hi/Lo 8-Or-Better Poker Simulation by ev++ Equity Calculator :: Enumerated 600000 hands

Player	Hands	Combos / %	Win Hi %	Tie Hi %	Win Lo %	Tie Lo %	Scoop %	Equity %
1	AcAd2c3d	1 / 0.0%	18.96	0.39	28.13	14.99	12.14	30.82
2	****	270725 / 100.0%	7.93	2.28	1.03	2.38	4.01	7.70
3	****	270725 / 100.0%	7.88	2.29	1.03	2.39	4.00	7.68
4	****	270725 / 100.0%	7.87	2.28	1.00	2.36	3.98	7.64
5	****	270725 / 100.0%	7.92	2.28	1.01	2.37	4.01	7.68
6	****	270725 / 100.0%	7.93	2.31	1.01	2.36	4.01	7.69
7	****	270725 / 100.0%	7.86	2.31	1.01	2.37	3.98	7.65
8	****	270725 / 100.0%	7.91	2.31	1.02	2.37	4.03	7.70
9	****	270725 / 100.0%	7.96	2.28	1.01	2.35	4.06	7.72
10	****	270725 / 100.0%	7.95	2.32	1.01	2.39	4.01	7.72

Rather, each random hand would consist of C(48,4) = 194580 starting hands that do not contain any of Ac, Ad, 2c, or 3d.


That something involving excessive hand ranges is slowing down calculations is certainly clear. When I run a calculation comparing two specific hands and with three specific flop cards, the results take much longer than necessary. It is easy to see why (at least in this case):


Omaha Hi/Lo 8-Or-Better Poker Simulation by ev++ Equity Calculator :: Enumerated 600000 hands
Board Cards :: A 5 K

Player	Hands	Combos / %	Win Hi %	Tie Hi %	Win Lo %	Tie Lo %	Scoop %	Equity %
1	AcAd2c3d	1 / 0.0%	52.53	6.11	0.00	54.47	22.24	52.53
2	2h3h4sKs	1 / 0.0%	41.37	6.11	17.32	54.47	20.06	47.47

Clearly, there is no need to do 600000 simulations when the actual results can be computed exactly by choosing two more cards out of the 41 remaining in the deck. So C(41,2) = 820 different possible turn + river cards; the calculation should be nearly instantaneous.

Other speedups might result from the use of the recognition of isomorphisms among the generated subsets of random cards. It's been a long while since I've done any real coding, so I am only guessing that such techniques would save processing time.

Yeah, this is already done with respect to the board /dead cards. But you're right, throwing out the cards from players who only have 1 hand in their range is easy enough to do and may provide some improvement.

Yep. Right now I am just dumping everything to Monte Carlo which is clearly silly in situations like you outline. I initially did this because it was simpler and the MC sims were so fast for analagous situations in Holdem. Unfortunately this doesn't carry over to Omaha (you have to do 60 times as may hand evaluations for Omaha) but this is one of the things I will be implementing asap.

I have not done much research on this, but my understanding is that in many situations this is true. I'm not sure how true this is in situations where you are forced to do MC or whether the coding effort would be worth the extra speedup.

Sorry, this recommendation was a holdover from my years working in a university Math Department. Nowadays computers are so fast that brute force methods are not only simpler to code, but are often just as quick anyways.

Guest Article: "Combinatorics Resources For Aspiring Math-Geek Poker Players"

Should be fixed now.

Omaha Hi Poker Simulation by ev++ Equity Calculator :: Enumerated 600000 hands
Board Cards :: 2 2 9

Player	Hands	Combos / %	Win Hi %	Tie Hi %	Equity %
1	KhJd7d2c	1 / 0.0%	28.20	3.84	30.12
2	****	211876 / 78.3%	7.38	0.81	7.78
3	****	211876 / 78.3%	7.38	0.81	7.78
4	****	211876 / 78.3%	7.41	0.81	7.81
5	****	211876 / 78.3%	7.36	0.79	7.75
6	****	211876 / 78.3%	7.39	0.80	7.79
7	****	211876 / 78.3%	7.33	0.80	7.72
8	****	211876 / 78.3%	7.36	0.78	7.75
9	****	211876 / 78.3%	7.34	0.76	7.72
10	****	211876 / 78.3%	7.39	0.81	7.79

The calculations are still not as fast as I would like when there is that many random hands but short of shelling out for a more powerful server I'm not sure there is a whole lot more speed I can squeeze out of it. The main bottleneck is now the underlying poker-source code which I think has already been highly optimized.

edit: Just out of curiosity were you just stress testing the calculator or did you find games where you are regularly getting it in against 9 random hands...PM me with site info if the latter

You are using random hands based on the absence of the board cards only. So C(49,4) = 211876, as indicated. However, there are seven cards that are known: the three board cards and the four specific cards in the hand of player 1. So there should actually be C(45,4) = 148995 different possible random hands for ****.



I definitely look forward to a downloadable version that I can run on my own computer so that I do not have to "share" processor time with other web users out there.

No, I'm doing a lot of research on hand equities, both short-handed and full-ring. I have a *lot* of research I want to do, not just on O8 but other games as well. Your tool is very, very helpful to me, sir. I greatly appreciate it. And if my reports help you improve this tool, well ....

Yes I'm only discounting board and dead cards right now but this will be accounted for in the same patch that enumerates all possible hands when everyones range is perfectly defined..


Glad to hear it, is nice to have someone helping to make it a better resource!

Done.

Omaha Hi Poker Simulation by ev++ Equity Calculator :: Enumerated 600000 hands
Board Cards :: 2 2 9

Player	Hands	Combos / %	Win Hi %	Tie Hi %	Equity %
1	KhJd7d2c	1 / 0.0%	84.90	1.08	85.43
2	****	148995 / 55.0%	14.03	1.08	14.57

..and done.

Omaha Hi/Lo 8-Or-Better Poker Simulation by ev++ Equity Calculator :: Enumerated 820 hands (Exhaustive)
Board Cards :: A 5 K

Player	Hands	Combos / %	Win Hi %	Tie Hi %	Win Lo %	Tie Lo %	Scoop %	Equity %
1	AcAd2c3d	1 / 0.0%	52.44	6.10	0.00	54.51	22.20	52.45
2	2h3h4sKs	1 / 0.0%	41.46	6.10	17.32	54.51	20.12	47.55

These changes also make the street by street calculations much faster when cards are known.

Yes, the calculations do seem significantly faster than before. Thank you so much!

I have one last hand range request, because I have trouble with getting the syntax correct for complex hand range expressions. Could you add a letter to designate ten-point cards? Perhaps this could be specified with the letter "e," so

E = K, Q, J, or T.

This would be helpful when examining hands with high cards but no Ace, a very common type of situation in most of the games.

Beyond this, I could only hope for a downloadable version to use offline. OK, maybe the hand range syntax could be simplified and made more uniform, but I'm getting picky, so I'll stop.

Glad to hear there has been a noticeable speed improvement. I'll add the E cards tomorrow....soon we will have every three and 4 card comb covered

Good to go

I'm having problems running combos for a range of 6%. It keeps cutting out AQo. In stove 6% is 88+,ATs+,KQs,AQo+. This is 86 combos, but I do the combos in the program and it only comes out to 74 because it's not including AQo.

Hey Guitarizt ,

This difference is due to the ev++ calculator only including hands that are within the top 6%. 74 combos is 74/1326=5.6% while adding in the 12 combos of AQo takes you to 86/1326 = 6.5%, slightly outside 6%.

I'm not sure one way or the other is better but I made that decision when I implemented it because I personally prefer the "within the top x%" interpretation.

You can get the pokerstove top 6% by doing 6%|AQ

Thanks neko. I've learned how to put the actual hands in the hand ranges in now too instead of putting in the %.

Good to hear. Let me know if you need any help constructing hand ranges. FWIW for Holdem you can also click on the Player link beside the range and it will bring up a tool that you can use to pick hands.

Bump to say I finally got around to adding permalinks for sims so you can now bookmark sims or post links to a sim for other people like so:

http://www.evplusplus.com/poker_tool...nge_type=stove

There appear to have been made additional speed improvements, and I really like the display of multiple results, one after another on the same webpage with permalinks.

I have a few suggestions for syntax improvements, but first I would like to recommend the inclusion of ...

THE BOARD RANGE TOOL.

This would work similarly to the hand range tool, but would consist of generating ranges for 3 cards (after flop), 4 cards (after turn) and 5 cards (after river). Presently, you can use the hand range tool for Omaha hands to examine different types of 4 card boards (i.e., after the turn card is dealt). But to be really useful, this would be incorporated in the odds calculator, so that I can examine equities after certain types of flops, turns, & rivers. As far as I know, this type of flexibility is not available from other odds calculators, which require exact specification of cards on the board.

So, for example, suppose I put my opponent on two broadway cards, excluding pairs, and I have ducks:

Holdem Poker Simulation by ev++ Equity Calculator :: Enumerated 600000 hands

Player	Hands	Combos / %	Win Hi %	Tie Hi %	Equity %
1	rr{np}	160 / 12.1%	49.38	0.90	49.83
2	22	6 / 0.5%	49.72	0.90	50.17

It's a coinflip, as expected. But ... I want to know how much equity I have after a paired flop. So in the board field, I would specify:

***{op}

which would be any three-card flop containing a pair.

Or suppose I want to know my equity after the turn card, when the board consists of four middle cards with one pair. So I would specify the board field as such:

MMMM{op}

Presently, I can generate ranges for any four-card combinations using the hand range tool and specifying Omaha hands. In this particular case, MMMM{op} would be this range:

http://www.evplusplus.com/poker_tool...ertools&page=1

Of course, we start to get into large numbers of combinations when we look at board ranges after the river card is dealt, but in practice this ought to be calculable in a reasonable amount of time based on the card/range limitations given in the hand fields, since we are most likely going to be specifying narrow hand ranges to compare against each other given different board textures.

This idea naturally leads us to ...

THE MUCK RANGE TOOL

(or dead card range tool, if you prefer). Suppose (in Hold'Em) an early position player limps, and the button raises, and we call in the big blind. Then the early position player shoves, and the button tanks and then folds.

We put the button on a middling ace or medium pair. This could be specified by

AM | MM{op}

in the dead card field. So we could generate the equity of our hand, whatever it is, against the early position player's limp/shoving range, given the likely cards mucked by the button. In theory, there would be (almost) no limit to the number of possible cards in the muck range tool. In practice, there would have to be *some sort* of limit.

I hope I have made my request clear. If not, I can go into more detail with more examples, if that will help. I believe the addition of these capabilities would make your odds calculator very desirable

Of course, the same code can be used to add 3-card, 4-card, & 5-card stud hands to the hand range tool.

Yes this would be a very nice feature.

These types of calculations can certainly be done, but are not easily achieved with the back end equity calculator I have used. This may be something I revisit down the line but unfortunately I wouldn't be holding my breath waiting for that to appear online soon.

Agreed, I think that it should be tractable even for 5 card boards given reasonable limitations on ranges/boards.

So I would say regarding Board Ranges is that I can add 3 card combos(and 5 card as long as it is not prohibitively slow) to the hand range tool but adding that functionality to the equity calculator is a ways down the road.

BTW As a workaround for generating 3 card boards with the hand range tool right now you can just specify one card exactly as long as it isn't part of the range you are interested in. For example BBB2c{op}.

I have discussed this sort of idea already with another member and think it is a great idea but not really feasible with the current back end. I am working on writing my own back end so hang tight...I am a mediocre programmer working on this part time but I am doing what I can

You have been very clear thanks! BTW you also have the nicest formatted posts of anyone on 2+2!