Got couple of questions about Roulette, if anyone knows...

[mjr]

Not expressing an opinion one way or the other on gambling, that's for fratching.

Anyway, this story:

http://thedailywtf.com/articles/Knoc...-Off-The-Perch

Got me thinking about the strategy a little deeper. So, an American roulette table has 38 total spaces, 2 green, and 36 red/black (18 of each). Meaning that there is a 1/19 chance of hitting a green, and an 18/19 chance of hitting any other color. And obviously, the odds of hitting a red/black aren't 50%.

If I understand the payout correctly, if you bet on red or black (no number specifically), the payout is 1:1.

So let's say I bet $10, and I win. Then I get back the $10 I bet, plus the $10 I won, correct?

If that is indeed correct, the data I got from my experiment was very, very interesting. Because it seems I always came out ahead.

I modified the story above, but instead of using 4 in a row, I simply used 2 in a row. I started out with a $100 bankroll, and "placed" minimum bets of $10 when the criteria were met.

So I threw together a C# program that does the following:

1. "Spins" a roulette wheel.
2. Logs whether its a red/black (green coming up would reset both counts).
3. When two consecutive spins of a color come up, make a minimum bet (i.e. $10) on the opposite color. So if two consecutive reds come up, bet black, and vice versa.
4. If the bet is successful, zero out red/black count, collect $$$ and go to #1.
5. If the bet is unsuccessful, bet 1.5x the amount (i.e. $15) on the same color as before (i.e. the previous black bet failed, so bet black again)
6. If that bet is successful, zero out red/black count, collect $$$, and go to #1. If the bet is unsuccessful, zero out red/black count, subtract loss, and go to #1.

I set 100 spins as the minimum, so during the course (because of #5 above) of the experiment there can be more than one hundred spins.

So I did 100 sets of 100 spins (10,000+ spins). What I found was fascinating.

Using this strategy, I always came out ahead, for some reason, during every single iteration of 100 spins. There were a low amount of bets placed (both numerically and by percentage), but the "payouts" usually totaled in the $400 - $500 range after each "round" of just over 100 spins. The "win percent", though, hovered around 50%, which I found odd. However, Wikipedia says that in American Roulette, the odds against winning are 1 1/9 to 1.

I'm not sure if this is something in my code that isn't right, or what, but it seemed odd to me that I never "lost" money overall, and, in fact won a good deal.

The percentage of bets to spins was between 20 and 34 or so.

So since the program takes some time to run (I'm looking into speeding it up), I started it this morning, but instead of betting after two in a row, I'm having it bet after three in a row.

I'm compiling the data in a spreadsheet.

Maybe next time I'll significantly reduce the number of spins, and see if that makes a difference. Maybe I'll reduce it to 10 or 20.

[wolfie]

I can see 2 problems:

1) Waiting for 2 in a row and then betting the opposite relies on the principle "the dice have memory". They don't - your system relies on the Gambler's Fallacy.

2) Your system sounds like a variant of the Martingale, a system which produces a large number of small wins but a small number of large losses.

Here's my analysis:

Win first bet 18/38 or (18x38)/(38x38) or 684/1444 chance, win $10

Lose first bet 20/38 chance

If you lose the first bet, you have a (20x18)/(38x38) or 360/1444 chance of winning $5 ($15 win on second bet less $10 loss on first) and a (20x20)/(38x38) or 400/1444 chance of losing $25 (sum of the 2 bets).

Expected results are ((10x684)+(5x360)-(25x400)/1444) = (6840+1800-10000)/1444 = -1360/1444 = -340/361 = -0.94 (to 2 decimal places).

In short, when run repeatedly you can expect to lose an average of 94 cents on each cycle of bets.

Compare this to simply betting $10 on black every time. Your expected results are ((10x18)-(10x20)/38) = (180-200)/38 = -20/38 = -0.53 (to 2 decimal places), or an average loss of 53 cents on each bet.

There's a reason casinos LOVE people who use systems (structuring their bets in a situation where the odds are the same on each bet). Contrast this to card counting in Blackjack, where the odds change on each hand and the player adjusts their bet based on the odds - card counters get banned from casinos.

[mjr]

I can see 2 problems:

1) Waiting for 2 in a row and then betting the opposite relies on the principle "the dice have memory". They don't - your system relies on the Gambler's Fallacy.

2) Your system sounds like a variant of the Martingale, a system which produces a large number of small wins but a small number of large losses.

This is why I conducted the experiment. And I found the results incredibly odd, because they weren't what I actually thought they'd be.

[Nunavut Pants]

Remember that random number generation on computers is a very tricky thing; there has been quite a bit of research into it. Most of the random functions aren't actually very random, so you could easily be getting hit with that.

Here's a little information on the subject, if you're interested: https://en.wikipedia.org/wiki/Random_number_generation

[mjr]

Remember that random number generation on computers is a very tricky thing; there has been quite a bit of research into it. Most of the random functions aren't actually very random, so you could easily be getting hit with that.

Here's a little information on the subject, if you're interested: https://en.wikipedia.org/wiki/Random_number_generation

Oh, sure, I get that random numbers on computers are tricky things. I threw this together in C#, more from a theoretical and a curiosity standpoint. That's basically what the guy in the article did. I just wanted to see what kind of results I could get if I modified it a little. The results were still surprising.

[csquared]

Remember, random number generation is too important to leave to chance!

[mjr]

Compare this to simply betting $10 on black every time. Your expected results are ((10x18)-(10x20)/38) = (180-200)/38 = -20/38 = -0.53 (to 2 decimal places), or an average loss of 53 cents on each bet.

This is intriguing. I may have to cobble together another quick program that does just this...and see the results.

[wolfie]

The reason for the average loss on the cycle of bets being higher than that on a single bet is probably related to the cycle having 2 bets (roughly) half the time, with the second bet in the cycle being larger (and therefore having a larger potential loss) than the first.

You're also running a fairly small number of tests, so streaks and slumps can have a significant impact. "Monte Carlo" simulations typically go for at least a million iterations to get closer to the average result.

I'd suggest the following changes:

- Run more cycles (don't know why the program would be slow - it's fairly simple, with minimal calculation)
- Capture the result of each "spin" (whether or not your system has you betting on that spin), and at the end print out how many times each number came up. If you get some numbers coming up much more often than others, that's a sign that your random number generator isn't up to snuff.

[mjr]

You're also running a fairly small number of tests, so streaks and slumps can have a significant impact. "Monte Carlo" simulations typically go for at least a million iterations to get closer to the average result.

I'd suggest the following changes:

- Run more cycles (don't know why the program would be slow - it's fairly simple, with minimal calculation)

I put in a 1.5 second delay between each "spin". I'll have to take that out and test it over a few million iterations to see how things go.

- Capture the result of each "spin" (whether or not your system has you betting on that spin), and at the end print out how many times each number came up. If you get some numbers coming up much more often than others, that's a sign that your random number generator isn't up to snuff.

Good idea. I think I'll incorporate that. Though I used the built in C# random number generator.

[Nunavut Pants]

PREFACE: I hope that links to books Amazon that are germane to the topic on hand are considered OK.

Other things that can have an effect on your simulation include the number of times you get the same results in a row, or you get repeating sequences, and on and on.

If each bet really does have a slightly less than 50% chance of paying off (17/36) and the numbers actually come up randomly, you always lose in the long term.

Note that the numbers on a roulette wheel do not necessarily come up randomly. The rotation speed of the wheel, when the person running the game releases the ball, the position of the wheel when they release the ball, how fast they release it, and so on all affect the numbers. Some folks can actually target a specific number and hit it with a far larger amount of success than 1 in 36... Read "The Eudaemonic Pie" if you'd like a bit of a tutorial on that, along with some history of an early-ish period of the tech industry.

[ComputerNecromancer]

Actually, you shouldn't be using a random number generator at all.

The "proper" way to analyze this sort of thing is to use nested for-next loops to run thru all the possibilities.

fill in the appropriate" bins (cells in a matrix or whatever) and then compare totals.

[Nunavut Pants]

The "proper" way to analyze this sort of thing is to use nested for-next loops to run thru all the possibilities.

When you have a setup like this that relies on multiple random-ish events, the number of possible combinations gets really large, really fast. (Literally "exponentially fast"!) And you have to think about how many tests in a row you want to enumerate; if it is five or ten or a thousand in a row, that has a whole lot of effect on how many total tests you have to run.

And, of course, it doesn't account for the roulette tables not being completely random, either.

[mjr]

And, of course, it doesn't account for the roulette tables not being completely random, either.

Which sort of ties into pseudorandom number generators, like the C# one. And why I'm surprised at the results I got.

[Nunavut Pants]

Well, the wheel not being random and the generator not being random does not make them equivalent. They are likely to be non-random in very different ways...

[Chromatix]

The physical wheel is predictable *if* you have precise data about the ball's initial trajectory, etc. This data is hard to come by in a casino setting.

Old 24-number wheels were also notorious for often being rigged in some way, or just being badly made to the point where a measurable bias was present.

Modern 36-number wheels, however, are close enough to uniformly random that it makes no practical difference. You can simulate them accurately with a high-quality PRNG.

Of course, the quality of PRNGs varies wildly. The rand() function (or equivalent) in the standard system library of many programming languages is notoriously poor, and in particular tends to exhibit strong short-cycle patterns in the low-order bits. This makes the typical strategy of taking the remainder of a division risky, when you're trying to simulate a "system" that looks for exactly those sorts of pattern.

A reliable PRNG over a limited range can be constructed by using Mersenne Twister (mt19937ar.[ch]) as a primary generator, then conditioning the output as follows:

#include "mt19937ar.h"
#include <stdint.h>

/* Returns a uniformly distributed random integer in [0,N) */
uint32_t uniform_0_N(uint32_t N)
{
    uint32_t max = ((1ULL << 32) / N) * N - 1;
    uint32_t x;

    do {
        x = genrand_int32();
    } while(x > max);

    return x % N;
}