Slot Machine Standard Deviation
Used algorithm is this:
N++;
sumXi += Math.pow(x, 2);
tmp += x;
sumXiSquare = Math.pow(tmp, 2);
sigma = 1/N * Math.sqrt((N*sumXi) - sumXiSquare);
where x is Totalwin (includes win bonus), N is number of spin, meanwhile sumXi and SumXiSquare variables are sum of previos values.
Testing it on simple series SD (sigma) get rigth value, but i'm not sure if assing to "x" totalWin or assign "Total Bet - TotalWin" value.
Somebody correct me if I'm wrong, but I think the method for calculating the SD for a slot machine is:
(a) Calculate the mean payout
(b) For each distinct payout amount, including zero, multiply the probability of getting that amount by (payout - mean)2
(c) Add up all of the values in (b) (this should be the game's variance)
(d) Take the square root of the sum in (c).
Note that this is for one spin - for N spins, I think you multiply the one-spin SD by the square root of N.
The problem is, there's no way of knowing the probabilities with any degree of certainty.
Quote: ThatDonGuy
The problem is, there's no way of knowing the probabilities with any degree of certainty.
Sure there is, just look at the PAR sheet. :)
Using these values : 2,4,4,4,5,5,7,9 standar dev result to be 2 as my function return.
Now i need to deep under the hood and discover your quote about the probability...
Any suggestion will be very appreciate :)
About slot machine doesn't exist yet, but i develop a visual simulator that use virtual reel taken from atkins diet slot, as i tested with accuracy algorithm and statistical value. To complete my goal remains to calculate SD and Volatility.
it is not enough to ponder these real values ?
Quote: blackbaronBut why use probabilities on SD ? In my case i can simulate N spin and give real win values.
it is not enough to ponder these real values ?
You can do it that way, but it's not quite as accurate.
To answer your original question, you do have to include all of the spins where the result is zero.
Think about it; if you were doing it with tossing a coin, but not counting the losses, then all of the results would be 1, and the standard deviation would be 0.
Quote: ThatDonGuyYou can do it that way, but it's not quite as accurate.
To answer your original question, you do have to include all of the spins where the result is zero.
Think about it; if you were doing it with tossing a coin, but not counting the losses, then all of the results would be 1, and the standard deviation would be 0.
Tossing coin is a simple example to count zero too :)
what about sd value for not progressive slot in production mode ? i read some different value accepted, any indication from real experience ?
Quote: blackbaronwhat about sd value for not progressive slot in production mode ? i read some different value accepted, any indication from real experience ?
There's no way of knowing the SD without knowing the particulars of the payouts.
In "the old days," most slot machines had 3 reels, and each reel had 20 stops, so there were 8000 different possible results.
Suppose you were at a machine that advertised, "99% payback" - that is, the expected return for a $1 bet was $0.99.
Now, if the machine had 7920 combinations that lost and 80 that paid $99, the mean return is (80 x 99)/8000 = 0.99, and the SD is:
sqrt( ( (7920 x (0 - 0.99)2 + 80 x (1 - 0.99)2 ) / 8000 ) = 0.011
However, if the machine has 800 combinations that lose and 7200 that pay $1.10, the mean return is still (7200 x 1.1) = 0.99, but the SD is now:
sqrt( ( (800 x (0 - 0.99)2 + 7200 x (1.1 - 0.99)2 ) / 8000 ) = 0.33, or about 30 times as high.
(1) The total RTP of the game is the mean.
(2) I'd cycle through all possible combos to calculate the distance of the result from the mean (including 0 for no win).
(3) I'd calculate the average of the squares of the distances from the mean.
But, um, scatters trigger bonus round with free spins, which can win more free spins. Ugh. The recursion makes my head hurt.
I guess I could simulate a billion spins and figure the distance from the mean for each spin that way. But is there a way to calculate and not simulate? That's not incredibly painful?
The exact answer requires the exact probabilities. There is no way around this. So you have to calculate the probabilities of different outcomes for bonus triggers and retriggers, free games, etc. In fact, you cannot calculate the RTP without these probabilities. But your start out assuming you have (1) The total RTP of the game. You cannot use a formula without the values of the variables.Quote: MichaelBluejayI'd like to calculate the SD of some slots I've programmed and at first I thought it would be straightforward:
(1) The total RTP of the game is the mean.
(2) I'd cycle through all possible combos to calculate the distance of the result from the mean (including 0 for no win).
(3) I'd calculate the average of the squares of the distances from the mean.
But, um, scatters trigger bonus round with free spins, which can win more free spins. Ugh. The recursion makes my head hurt.
I guess I could simulate a billion spins and figure the distance from the mean for each spin that way. But is there a way to calculate and not simulate? That's not incredibly painful?
link to original post
33,554,432 combos (5x3)
64.18% Payline RTP
06.98% Scatter pays RTP
26.88% Bonus game (free spins) RTP
98.03% Total RTP
Probability of x scatters (which trigger bonus round of 10 spins with wins tripled):
3 scatters paying 5: 353,916 / 33,554,432 = 1.05%
4 scatters paying 25: 20,908 / 33,554,432 = 0.06%
5 scatters paying 100: 486 / 33,554,432 = 0.001%
3+ scatters: (353,916 + 20,908 + 486) / 33,554,432 = 1.12%
Avg. number of spins per bonus round: 11.26
Avg. win per bonus round: 24
------
Is that enough data to figure the SD of the game? As I said, I could do it for line pays and scatter pays pretty easily, by doing a cycle test and summing the difference of squares for each combo, but the bonus game is throwing me.
It looks like you have data from a PAR sheet or something similar. Whoever calculated RTP, 'Avg. number of spins per bonus round' and 'Avg. win per bonus round' must have had the primary data that you would need to calculate the variance.Quote: MichaelBluejayWell, I have all that. For one slot:
33,554,432 combos (5x3)
64.18% Payline RTP
06.98% Scatter pays RTP
26.88% Bonus game (free spins) RTP
98.03% Total RTP
Probability of x scatters (which trigger bonus round of 10 spins with wins tripled):
3 scatters paying 5: 353,916 / 33,554,432 = 1.05%
4 scatters paying 25: 20,908 / 33,554,432 = 0.06%
5 scatters paying 100: 486 / 33,554,432 = 0.001%
3+ scatters: (353,916 + 20,908 + 486) / 33,554,432 = 1.12%
Avg. number of spins per bonus round: 11.26
Avg. win per bonus round: 24
------
Is that enough data to figure the SD of the game? As I said, I could do it for line pays and scatter pays pretty easily, by doing a cycle test and summing the difference of squares for each combo, but the bonus game is throwing me.
link to original post
Forget the bonus rounds. You have nothing that even hints at the variance of the base game. If I understand your problem, you know that 100%-1.12%= 98.88% of games are base games. You know nothing else except that the base game is returning 64.18%. If you have the reel strip frequencies and pay table, then you could calculate the variance due to the base game. You could also calculate the bonus rounds, but I agree it would be a bit of a headache because you can have infinite bonus retriggers unless the rules preclude this. (Many game have a cap on bonus retriggers.)
Well, like I said, I can figure the SD of the line pays and scatter pays by cycling through all the combos and getting the squares of the differences. It's the bonus game that I don't know how to calculate.Quote: MentalForget the bonus rounds. You have nothing that even hints at the variance of the base game.
I guess I'll just simulate a billion rounds and figure the difference from the RTP for each spin.
So, how did you get the RTP without knowing the probabilities for each payout?Quote: MichaelBluejayI guess you missed where I said that I programmed the slot, so I have access to all the data.
Well, like I said, I can figure the SD of the line pays and scatter pays by cycling through all the combos and getting the squares of the differences. It's the bonus game that I don't know how to calculate.Quote: MentalForget the bonus rounds. You have nothing that even hints at the variance of the base game.
I guess I'll just simulate a billion rounds and figure the difference from the RTP for each spin.
link to original post
I suppose you could have calculated the value of a 10 tripled free games to the value of the trigger, and then recursively figured out the probabilities for each number of retriggers. Thus, you could have calculated the RTP without calculating the probabilities of each outcome.
Let me ask you this. If you know the variance of a single spin, do you know how to calculate the variance of 10 tripled free games?
Why is it you think I don't know that? As I said, this is a slot that I programmed. I got the payline RTP by cycling through all the combos and adding the return for each combo.Quote: MentalSo, how did you get the RTP without knowing the probabilities for each payout?
No. That's pretty much what I said in my original post.Quote: MentalLet me ask you this. If you know the variance of a single spin, do you know how to calculate the variance of 10 tripled free games?
Quote: MichaelBluejayI'd like to calculate the SD of some slots I've programmed and at first I thought it would be straightforward:
(1) The total RTP of the game is the mean.
(2) I'd cycle through all possible combos to calculate the distance of the result from the mean (including 0 for no win).
(3) I'd calculate the average of the squares of the distances from the mean.
But, um, scatters trigger bonus round with free spins, which can win more free spins. Ugh. The recursion makes my head hurt.
I guess I could simulate a billion spins and figure the distance from the mean for each spin that way. But is there a way to calculate and not simulate? That's not incredibly painful?
link to original post
Questions: how is the number of free spins determined, and how is the number you can get from a particular free spin determined? Once you know the probabilities, there should be a way to calculate the variance.
It seems that you are able to handle recursion for the RTP but not for the variance and StdDev. That is nothing to be ashamed of, because the latter is much trickier.Quote: MichaelBluejayWhy is it you think I don't know that? As I said, this is a slot that I programmed. I got the payline RTP by cycling through all the combos and adding the return for each combo.Quote: MentalSo, how did you get the RTP without knowing the probabilities for each payout?
No. That's pretty much what I said in my original post.Quote: MentalLet me ask you this. If you know the variance of a single spin, do you know how to calculate the variance of 10 tripled free games?
link to original post
Do you mind if I pose a simpler example with bonus rounds? Maybe I can see if we are on the same page.
In my game, I roll a die at a cost of 5 units. If the roll comes up R=1-5, I get paid R units (Ru). If I roll R=6, I get 2 bonus rolls at 3*Ru payouts plus 6u. I am capped at 3 bonus rounds. In any third bonus round, rolling a 6 just pays 3*6u. So the EV of the third bonus round is EV3=3.5u*3/6=10.5/6u. Then, the EV of a second bonus round is EV2=(3u*3+EV3)/6. The value of the first bonus round is EV1=(3u*3+EV2)/6. The EV of a base game is EV0=(3u*3+EV1)/6-5u. I am using the fact that the average R for a roll that is not a six is 3. (3.5 for the last roll where a six pays 6u.)
So, I can calculate RTP for the game based on a recursive formula for expectation value. (I don't want to spend a lot of time on this, so please check my math.) I assume you used some similar math to get your RTP and averages. Nothing I wrote helps me calculate variance or SD. I do not have the probabilities for the outcome of any single game, that is, any starting non-bonus roll that I paid 5u to play.
These games can be represented as sequences of numbers like 2, 6(24), 5, 6(6(13)4), etc. The best outcome is 6(6(6(66)6(66)6(6(66)6(66)). If I did this right, this has a probability of 1/(6^16) and nets out as (3*8*6u - 5u). This is just one term that you need to calculate the variance.
For your game with 10 free games and infinite recursion, this method of calculation becomes pretty intractable. You would need a nested loop in a computer program or an enormous spreadsheet to calculate the variance this way. I am guessing your initial post is meant to ask if there is a shortcut to combine the variances of the different bonus rounds into a simpler equation. I am not sure about this, but I would work out the math on a simpler example to be sure any such formula give the right answer.
I'm just using simple formulas for figuring the RTP from the bonus round (as taught to me by the Wizard over a decade ago). There's no recursion per se in the formulas, and I'm not running loops, let alone nested loops. Well, I'm running loops to go through every combo to figure the *line pay return* and the *scatter pay return*, and the probability of triggering the bonus round, and from that I can calculate the bonus round return.
The more I think about it, the more I think I should just simulate a billion or so rounds, get the total pay from each spin (and if 10 free games triggers 10 more free games which triggers 10 more free games, the total pay for all those games counts as one spin). Then I can figure the difference from the mean for each spin, etc. I mean, who could stop me?
I tend to go with Monte Carlo simulation as my first choice for any problem as complex as yours. Analytical calculations can be more precise than MC sims, but if you make a mistake in the math, then they are precise and wrong. If you already have code that plays the game correctly by your rules, then you can probably do a trillion sims in less time than you have spent on this thread.Quote: MichaelBluejayThank you, Mental.
I'm just using simple formulas for figuring the RTP from the bonus round (as taught to me by the Wizard over a decade ago). There's no recursion per se in the formulas, and I'm not running loops, let alone nested loops. Well, I'm running loops to go through every combo to figure the *line pay return* and the *scatter pay return*, and the probability of triggering the bonus round, and from that I can calculate the bonus round return.
The more I think about it, the more I think I should just simulate a billion or so rounds, get the total pay from each spin (and if 10 free games triggers 10 more free games which triggers 10 more free games, the total pay for all those games counts as one spin). Then I can figure the difference from the mean for each spin, etc. I mean, who could stop me?
link to original post
Good luck with your game.
Quote: MichaelBluejayI posted that above.
link to original post
Assuming each set of 3+ scatters generates 10 more free spins, the expected number of "sets" of 10 free spins that are generated from a set of 10 spins is:
0 q^10 + 1 C(10,1) p q^9 + 2 C(10,2) p^2 q^8 + ... + 9 C(10,9) p^9 q + 10 p^10
where p is the probability of a spin generating a new set, and q = 1 - p
This equals 10 p, so the expected number of additional free spins generated in a set is 10 p, and the total when free spins from those free spins (and so on) are included is:
10 p + (10 p)^2 + (10 p)^3 + ...
= 1 / (1 - 10 p)
In this case, p = about 0.011185%, so the expected number of free spins in a bonus round that starts with 10 free spins is 10 + 1.126 = 11.126.
mean = 0.99018 // Total game RTP
for (counter = 0; counter < totalCombos; counter ++) {
[code that spins and tabulates the result]
...
spinDifferenceFromMean = spinPayout - mean
spinDifferenceSquared = spinDifferenceFromMean ^2
runningAverageOfSquares = ((runningAverageOfSquares * (counter-1) ) + spinDifferenceSquared) / counter
}
Quote: MichaelBluejaySo I'm writing the code to do the difference from the mean (RTP) for each spin from a billion random spins, and I'm realizing that I probably shouldn't be keeping a billion numbers in memory until the and and then average their squares. Seems like I should keep a running tally, like with this pseudocode:
Howzat?mean = 0.99018 // Total game RTP
for (counter = 0; counter < totalCombos; counter ++) {
[code that spins and tabulates the result]
...
spinDifferenceFromMean = spinPayout - mean
spinDifferenceSquared = spinDifferenceFromMean ^2
runningAverageOfSquares = ((runningAverageOfSquares * (counter-1) ) + spinDifferenceSquared) / counter
}
link to original post
You have a logic error. When counter = zero, you want to multiply running ave by 0 and add the new value and divided by one. When counter = 2, You want to multiply running ave by 1, add new value and divide by 2, etc.
mean = 0.99018 // Total game RTP
runningAverageOfSquares = 0;
for (counter = 0; counter < totalCombos; counter ++) {
[code that spins and tabulates the result]
...
spinDifferenceFromMean = spinPayout - mean
spinDifferenceSquared = spinDifferenceFromMean ^2
runningAverageOfSquares = ((runningAverageOfSquares * (counter) ) + spinDifferenceSquared) / (counter + 1)
}
This code may suffer from an accumulation of small rounding errors if you use 32-bit floating point numbers. Use 64-bit doubles if you have them.
mean = 0.99018 // Total game RTP
for (counter = 1; counter < 1000000000; counter ++) {
[code that spins and tabulates the result]
...
spinDifferenceFromMean = spinPayout - mean
spinDifferenceSquared = spinDifferenceFromMean ^2
runningAverageOfSquares = ((runningAverageOfSquares * (counter-1) ) + spinDifferenceSquared) / counter
}
I thought you might have meant to initialize counter = 1;Quote: MichaelBluejayThank you, Mental. Actually, it was a typo. I'd meant to start the counter at 1, not 0. Zero is for arrays and things that are internally-counted starting at zero. For counting a billion spins, it's 1 to 1B, not 0 to 1B-1.
Howzat?mean = 0.99018 // Total game RTP
for (counter = 1; counter < 1000000000; counter ++) {
[code that spins and tabulates the result]
...
spinDifferenceFromMean = spinPayout - mean
spinDifferenceSquared = spinDifferenceFromMean ^2
runningAverageOfSquares = ((runningAverageOfSquares * (counter-1) ) + spinDifferenceSquared) / counter
}
link to original post
mean = 0.99018 // Total game RTP
sum = 0;
for (counter = 0; counter < 1000000000; counter ++) {
[code that spins and tabulates the result]
...
spinDifferenceFromMean = spinPayout - mean
sum += spinDifferenceFromMean ^2
}
AverageOfSquares = sum / counter
This version is simpler and avoids a boatload of floating point multiply/divide operations inside of the loop.
