Simulating Singer - Part 1

I've finally ironed out the problems in my Video Poker simulator. Turns out random numbers weren't as random as I expected, so had to recode part of the simulation. Also caught an "off by one error" that was making everything look a little better than it should be.

If you don't like long essays, you can skip to the next thread.

So, what I've been doing for starters is simulating playing Video Poker with two different goals : a win/loss goal, and a time based goal. The former is the way Mr Singer expouses : hit targets and leave. The latter is the classic Advantage Play : get the hands in on good pay tables machines, and results will come.

Note that in this description this is as far as I have got in simulating Rob Singer's 3 different systems (Romp Through Town, Advanced Romp and Single Play). Nothing in this really describes exactly his play methods (progression on loss, win/loss targets, special plays). I am unlikely to get to the situation where I can simulate the special plays using my current architecture. No-one should be reading this as a critique of Rob Singer's plays (positive or negative). It's a starting point, offered up to all for critique in what I've found, to see if my simulation actually holds water before looking at any real "system" (AP, Singer Poker or other).

I am willing to take requests, it should be possible to simulate many different systems of VP, and even other one shot games like Sic-Bo, Roulette and Blackjack. I can't say I'll actually run them.

Assumptions
I have assumed that the VP machine is random.
I have assume that the player plays perfect startegy (based on the Wizards Tables).
Each hand is simulated by generating a random outcome, with the probability based on the tables from the Wizard's VP guides.
It does not deal each hand, select holds and then run the draws. If that seems "incorrect" to you, let me know why. If you just want something more, write your own.

The scripts are written in Groovy. I can pass them on if someone who knows that language wants to play with them.

Simulation Set 1
Based on a conversation on the original Singer thread, JerryLogan stated that most VPers are up at some point in their session. This seemed on my gut feel wrong. So my first simulation was to play $1 Video Poker with $500 credits, and play until you are up $5, or lose the bank roll.

A session here is defined by winning $5 or losing $500.

I ran 10,000 sessions.

VP Machine	EV	Winnning sessions (%age)	Final Bank roll	Average per session	Average Winning session	Average Losing session	Average Number of Hands
Bonus Poker 8/5	99.1%	92.5%	-$95,615	-$9.56	$30.20	-$500	123
Jacks Or Better 8/5	98.4%	92.1%	-$78,285	-$7.83	$34.68	-$500	122
Full Pay Deuces Wild	100.7%	92.0%	$50,605	$5.06	$49.04	-$500	116
Super Double Bonus	99.7%	82.6%	-$37,570	-$3.76	$100.85	-$500	118

So there, as mentioned elsewhere is a method to get Over 90% winning sessions. This also means, with deep enough buy in (100 hands in this case) you'll be ahead 90% of your sessions at some point. Of course there is no guarantee when this will be. It could be the first play or the 200th play.

My gut was wrong anyways, I had assumed it would be less than 50% of my session would I ever be ahead. To me, it's more obvious on reflection that because VP is not a Evens game, there will be more chance of being ahead than 50/50, but also times where you just dive to the bottom of the barrel.

Simulation Set 2

So to compare, I ran 10,000 sessions of 120 hands. Here the session is defined by time. 120 because it's roughly the same number of hands on average as the win/loss goal.

VP Machine	EV	Winnning sessions (%age)	Final Bank roll	Average per session	Average Winning session	Average Losing session	Average Number of Hands
Bonus Poker 8/5	98.4%	35.5%	-$40,215	-$4.02	$144.84	-$85.95	120
Full Play Deuces Wild	100.7%	36.2%	$44,385	$4.44	$170.86	-$90.31	120
Jacks Or Better 8/5	98.4%	36.0%	-$121,120	-$12.11	$111.03	-$81.44	120
Super Double Bonus	99.7%	27.9%	-$52,495	-$5.25	$352.18	-$143.29	120

Here we see the sort of session win/loss numbers that Bob Dancer estimates for Video Poker. Lot less winning sessions, but those that you do have are much bigger and the losses are less too. 120 hands is about 15 -20 minutes play, possibly less.

Note that with Simulation 1, some of those sessions will be very quick, while others may take several 100's of hands to complete. And on the flip side, with the 120 hand sessions, sometimes you may be up much higher than you end up with. Thats the give and take of using each type of end goal.

I'll leave it there for now. I've got some more numbers to run such as :

What's the effect of setting higher win goals?
What's the effect of having a lower starting bank roll?
Is there a positive effect if you stop in any system when you hit a Royal?
If I simulate a whole bunch of 100 sessions, what's the distribution like (100 sessions = 25h = 1 serious trip to Vegas)

Then also we can start to move towards Mr Singer's Advanced Romp through Town.

Comments?

Because I'm not one of the math guys and won't pretend to be like someone else who's bound to chime in, the only thing I can tell is that yes, players really do get ahead most of the time sometime during their play sessions. Beyond that, I can't tell what went down here. It looks impressive, but can you explain what happened in any other way?

In the meantime I'm watching my $1500 bet become positive.

Indeed, that was the unexpected result... with a $25 win goal on $1 VP it's around 80%. So there is my 90% session winning system for you. Free of charge. ;)

I may have a go at the Noddy and Big Ears description later on.

Quote: JerryLogan

Because I'm not one of the math guys and won't pretend to be like someone else who's bound to chime in, the only thing I can tell is that yes, players really do get ahead most of the time sometime during their play sessions. Beyond that, I can't tell what went down here. It looks impressive, but can you explain what happened in any other way?

In the meantime I'm watching my $1500 bet become positive.

Read the "Final Bankroll" column, Jerry.

Nice simulation. You've proved the obvious: you win at +EV games, and lose at -EV games, whatever the method. The Final Bankroll numbers tell all. Only the FPDW showed a profit; all other games showed massive losses, again, regardless of the method.

I hope, for Jerry's sake, that he believes this when he sees you rigorously proving it. He pisses on anything I say about it, because he wants to believe in Rob Singer, and wants to convince himself that his losing ways aren't his own fault.

Another interesting point is that the Thinger Thystem works for FPDW, like any Martingale would with a sufficient bankroll, in a +EV game. I presume, though, that you played optimally in your simulation, rather than going for some of Thinger's Thpecial Plays. It would certainly be possible to make enough such plays to turn FPDW into a -EV game.

What I'm not understanding is the final bankroll column differs so much on just a percent or so when there's only 120 hands played. And Singer can only lose $54,700 if he never wins a hand with 2400 credits, and only in single play. Where'd all those big losing numbers come from?

Quote: thecesspit

Assumptions
I have assumed that the VP machine is random.
I have assume that the player plays perfect startegy (based on the Wizards Tables).

Each hand is simulated by generating a random outcome, with the probability based on the tables from the Wizard's VP guides.
It does not deal each hand, select holds and then run the draws. If that seems "incorrect" to you, let me know why. If you just want something more, write your own.

Comments?

"incorrect" seems to be the correct word.
Because a simulation should have all the elements of the real world represented in it.
Having "the draw" is the way video poker is played.

Is it that difficult to program in Groovy for a deal and a draw based on a hold strategy card?

I need to break out my old Excel vba code for video poker.

Two quick points:

1) neither of these are a simulation of any Singer method. The first is similar. Not the same.

2) the big number is over all 10,000 sessions. Not on one session. See the average column for a per session number.

Quote: thecesspit

Two quick points:

1) neither of these are a simulation of any Singer method. The first is similar. Not the same.

2) the big number is over all 10,000 sessions. Not on one session. See the average column for a per session number.

What were the similarities and differences?

@Nope27 : I don't agree with needing to precisely simulate the deal and the draw. And here's why.

If I did, I'd end up with the same result I get from selecting a hand at random based on the probability charts. As each hand is independent, Ive got x% chance of getting a two pair result, y% of a flush and z% of a Royal. It doesn't matter if I deal out cards, run through a strategy card, do a redraw and then report the result.

I don't think I need to deal and draw any more than I need to simulate the physics of a pair of dice if running a craps simulation.

That said, I maybe missing out some subtlety I failed to take into account.

It certainly possible to write a full card-by-card simulation in Groovy. I'd have to spend a lot of time working on how to work out which play to make for a given draw, work out how to recognize each winning hand, and then code each strategy card for each variant. I don't really want to go down to that level (for THIS purpose at least. It'd be an interesting exercise for sure).

@JerryLogan : I do need to split out the 10,000 in to blocks, as I'm aware you and others don't like the long term and want to know what happens in the short term. Maybe that will make more sense to you. The distribution of results might be off interest. Though in case 1 it'll be really two blocks - -$500 or ~$5-50 profit, with a very few higher profit payouts.

The high percentage of "getting ahead" is counter-acted by the big loss when you wipe out (and those wipe out sessions will be long. I could also average the number of hands in a winning session versus a losing session).

@MKL : The three major differences are :

a) different (higher) session goals, and mini-win goals
b) moving to different machines at certain loss points
c) moving to different denominations at certain loss points
d) special plays.

I don't currently intend to use the latter, unless I code up a full simulator that nope27 suggests. I don't think there's much gain at present for me to do so.

Note also that a,b and c differ depending on which of the three strategies you are looking at. I have read most deeply into the advanced romp, and that will probably be my next set of sims.

Of course, MKL and JL are banned for now, but I am happy to have this debate with others as well :)

Quote: thecesspit

@Nope27 : I don't agree with needing to precisely simulate the deal and the draw. And here's why.

If I did, I'd end up with the same result I get from selecting a hand at random based on the probability charts. As each hand is independent, Ive got x% chance of getting a two pair result, y% of a flush and z% of a Royal. It doesn't matter if I deal out cards, run through a strategy card, do a redraw and then report the result.

I believe you are wrong with your thought. You would not end up with the same result.

Since the deal and the draw are different, the draw will change the outcome compared to just the deal being the final result.
That is what simulations are all about. So if you will try to duplicate Singers style of play, your results will not be correct, since you are not duplicating all the possible type of draws for a certain hand that he plays.

Quote: thecesspit

I don't think I need to deal and draw any more than I need to simulate the physics of a pair of dice if running a craps simulation.

To me, it sounds like you are just trying to take the easy way out with your coding.
The physics of a pair of dice means absolutely nothing in simulation. The rules of craps are the dice must hit the table and then the back wall. That produces a random roll. That is why a craps roll is easy to simulate. RNGs, for the most part, do a very good job of creating random results for a dice roll.

Quote: thecesspit

That said, I maybe missing out some subtlety I failed to take into account.
It certainly possible to write a full card-by-card simulation in Groovy. I'd have to spend a lot of time working on how to work out which play to make for a given draw, work out how to recognize each winning hand, and then code each strategy card for each variant. I don't really want to go down to that level (for THIS purpose at least. It'd be an interesting exercise for sure).

That is what I wanted to hear. The extra time would result in the proper coding to run an exact Monte Carlo simulation.
I am traveling for the holidays and look forward to code VP the way it is actually played and will share my results. Not the code.
I predict my session results will be different from yours, especially using Singers styles of play and his unique progressions through different denominations.
Thank you for your time.
Good Luck to you.

Quote: nope27

I believe you are wrong with your thought. You would not end up with the same result.

Since the deal and the draw are different, the draw will change the outcome compared to just the deal being the final result.
That is what simulations are all about. So if you will try to duplicate Singers style of play, your results will not be correct, since you are not duplicating all the possible type of draws for a certain hand that he plays.

I agree if I am trying to simulate Mr. Singer's special plays. I don't agree if I am trying to simulate perfect strategy.

To be clear, I am not JUST simulating the draw... I am simulating the end result after a player draws, holds and redraws.

Quote:

To me, it sounds like you are just trying to take the easy way out with your coding.

Absolutely I'm trying to make it easier for myself!

Quote:

That is what I wanted to hear. The extra time would result in the proper coding to run an exact Monte Carlo simulation.
I am traveling for the holidays and look forward to code VP the way it is actually played and will share my results. Not the code.
I predict my session results will be different from yours, especially using Singers styles of play and his unique progressions through different denominations.

I predict for 8/5 Jacks or better perfect strategy our results will be much the same, whichever system we try out.

I may well challenge myself to do a full simulation at some point, but that's not my current aim.

I'm going to start a new thread on this topic as I'd like a second opinion.

Cheers!

Quote: thecesspit

I predict for 8/5 Jacks or better perfect strategy our results will be much the same, whichever system we try out.

I may well challenge myself to do a full simulation at some point, but that's not my current aim.

I'm going to start a new thread on this topic as I'd like a second opinion.

Using a (correct) final distribution is equivalent to using a method that leads to it. If you know exactly the probabilities of each final hand in 8/5 JoB based on optimal play, you can use those. But I thought the point was that the Singer system makes different plays and, as a result, you don't know the probabilities of each final hand. Isn't that what you're trying to find out? In my mind, the right way to code that is to start with a generic deal/draw/eval engine and then a pluggable strategy module. That way you just change the strategy when you want to examine non-optimal plays.

Quote: MathExtremist

Using a (correct) final distribution is equivalent to using a method that leads to it. If you know exactly the probabilities of each final hand in 8/5 JoB based on optimal play, you can use those. But I thought the point was that the Singer system makes different plays and, as a result, you don't know the probabilities of each final hand. Isn't that what you're trying to find out? In my mind, the right way to code that is to start with a generic deal/draw/eval engine and then a pluggable strategy module. That way you just change the strategy when you want to examine non-optimal plays.

Correct is of course important... my original results (not published here) weren't correct and getting very skewed by a fault assumption on the RNG.

If I want to assess the effect of the special plays, this is true. I've had a very interesting email from Mr Singer and he says that these 5% of changes plays are very important to his strategies, so any simulation I do without them could not be considered a true simulation of his play style. However, I'm initially looking at the betting progressions rather than the plays themselves. I stated this in my assumptions/method.

I can certainly extend the VP object in groovy to be a lot more complex (the beauty of object orientated programming, eh). Mr Singer's plays would get harder as your strategy card would not only have to asses the hand, but also know the state of the bankroll. This is off course not impossible. I just don't fancy coding each and every strategy model (Deuces Wild, for instance is rather large)