Re: Programming to Beat the Odds in Gaming



Rickey said:

I am a person with limited programming skills. Professionally, I work as
a government engineer. Since my programming skills are limited, I am
seeking to partner with someone who possesses advanced programming skills
in order to develop a method for consistently beating the casino in a
perfectly legal way.

Okay, so the proposition is this: beat the house at roulette. This is a
little like Fermat's Last Theorem, in the sense that it's an attractive
problem for experts which also attracts a lot of cranks. In pre-Wiles
days, one professor got so many crank "proofs" of FLT posted to him that
he started handing them out to his students, together with a postcard that
said something along these lines:

"Thank you for proposing a proof of Fermat's Last Theorem. Unfortunately,
the proof contains one or more logical errors. The first such error is on
line _______, in which you claim ______________________________________.
This is wrong because __________________________________________________
________________________________________________________________________
________________________________________________________________________
_______________________________________________________________________.

Yours faithfully
The Mathematics Department
Such-and-such University"

The students' task was to analyse the proofs and fill in the cards. Quite a
fun project, for the right kind of mind.

Anyway, I will now take on the role of such a student, and look for your
first error.

I play one game only. It is roulette.

Well, that's arguably an error already - but Wiles played and won FLT, so
let's not be too dismissive at this stage.

The game of roulette is based on statistical probability which gives the
house a slim enough margin that the player would not be able to win
consistently over the long run.

The game is designed to meet the constraint that, in the long term, the
house always wins. The margin isn't all that slim, actually.

The closest strategy method which gives
the player any chance of breaking even at roulette is what is called the
Martingale.

That's an error right there. I *HAVE* broken even at roulette, over many
years, by the simple expedient of never playing it (or rather, never
playing it for money - when I was a child, my sister had a plastic
roulette wheel, red and black plastic counters, and a fold-up plastic
"table" *** - and even a tiny little croupier-style rake or whatever
it's called).

But even the Martingale cannot guarantee winning each time
the player plays.

That's because of the house advantage, the 0 (and, on some wheels, the 00
as well). In fact, the Martingale system guarantees losing, over the long
term.

<snip>

I am adequate at programming in the language of Adobe Flash, which is
Actionscript. I used Actionscript to build myself a few basic Martingale
programs. The idea was to test run simulations of walking into the casino
with as little as a couple thousand dollars and be able to double it.
Employing a modified Martingale strategy, I more than doubled my seed
money on numerous occasions.

Yes, well, you would, wouldn't you? Let's look at the effect of a
Martingale roulette strategy with a normal (single-0) wheel, right here
and now, with seed money of $2000. Our purpose is to double our money, so
the target is $4000. How often do we manage this?

To find out, I withdrew a million dollars from my bank account, and visited
no fewer than 500 different casinos, all around the world. I took $2000
into each. Naturally, the casinos were selected because they run an honest
game. (I have made this list of honest casinos worldwide available for
EXCLUSIVE purchase at the very reasonable price of two million dollars. No
warranty of accuracy or merchantability, express or implied, etc etc.)

The study took two years to complete (visiting an average of five different
casinos a week, not to mention all the tedious travelling to such dull
places as Monte Carlo, the Bahamas, and so on and so on). Fortunately, I
was able to use my time machine to make this process a little smoother; I
went back to April 2006 to initiate the study, so that I could make this
report before the thread fell off current newsfeeds. Yeah, I do have a
fabulous tan, thanks for asking.

In each case, I played a straight Martingale system - I started off with a
stake of $1. If I won, I banked my winnings (such as they were), and
reverted to a $1 stake. If I lost, I doubled my stake. I quit when and
only when: (a) I ran out of money; (b) I couldn't afford to double my
stake; or (c) I had reached the target of $4000 in that casino.

Well, the results were everything I'd dreamed of - in no fewer than 49 of
the 500 casinos, I proved that the Martingale system WORKS, DESPITE the
house advantage!

(What's more, my net loss of $481881 overall is of course tax-deductible,
so that's no big deal.)

However, over the long run, my winnings were
never consistent. Often I loss more times than I won. As an engineer, I
am obligated to know a lot of mathmatics. Statistical probabilities in
gaming are based on consistently uniformed betting patterns. One need not
be a rocket scientist to know, in a situation such as this, the key to
winning more than losing is for the player to vary his betting patterns
to such a degree that it is not, or does not seem to be, uniformed.

Here is your first real error. No, statistical probabilities are not based
on consistently uniform betting patterns. They are based on the likelihood
of particular events occurring.

For example, let's say you are offered evens on the outcome of the toss of
a coin, and you roll a die to decide how many dollars to stake: 1 = 1
dollar, 2 = twice previous bet, 3 = three times previous bet, 4 = repeat
previous bet, 5 = no bet, and 6 = think of a number <= your current purse.
So your betting pattern is completely unpredictable. NEVERTHELESS, in the
long run you will lose, if your purse is very small in relation to the
house purse (which it always is).

That is where the person with advanced programming skills come in.
I would need him or her to be able to design a program which can generate
thousands of trial run over a short period of time. In short, the program
would have to do what my programs are already doing manually. Moreover,
the program would be well written enough to be able to self-analyze how
many times it wins, how many times it busts, and adjust its betting
patters according.

How would it "adjust its betting patters according"?


If you are serious, I will share with you the
programs I have written thus far, which have built-in random number
generators mimicing roulette spins.

Um, gosh. You do realise that such programs can be rattled off in a few
seconds by anyone even remotely competent? Someone with "advanced
programming skills" can easily write such code with their eyes shut and
one hand tied behind their back (unless they use EMACS, obviously).

We can split all profits made.

That works for me, provided you cover all the losses.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.


Quantcast