about volitality

Hi there,
I find a book last week about casino management. It is one section introducing what's the meaning of the volatility of a game. As my understanding, volatility is just standard deviation. The payback of a game is the average of sample (each sample is a pay of a single game with unit bet). So the volatility is telling how many games we should play to win the average pay back. For a line game, in general, one could calculate the volatility by listing the hits and pay for each symbol as

Hit Pay
H1 P1
H2 P2
...
Hn Pn
Hz 0

So SQRT(sum{Hi*(Pi - P)^2}/N), here P is the average payback of the game, N is the cycle of the game. The book said it is very important to include the zero-pay entry, i.e. if Hz is all hits for all lost game, i.e. pay zero (Pz=0). We need to include that term to have correct volatility. In the book, it is said that Hz = cycle - sum(Hi, i=1 ... n). I don't understand why Hz is calculated this way but let's assume it is a correct way. So my question is do I have to worry how many lines being played in the game while calculating the vol? Let's say we are playing 30 lines, the hit is of course very different (though) proportional to that for 1 line. If 30 lines is considered, Hz = CYCLE - sum(Hi, i=1 ... n) may be negative because Hi may be very big (more lines used, more hits will be).

Similarly, if we play a 243 way games, Hz many be negative because Hi could be pretty big since it is a 243 way to go for each screen. So Hz is negative? What's wrong with my math and how do I fix it?

If I'm understanding this correctly, the cycle for the 243 line game will be a large number....and the Hz for such a game would likely be very low (compared to a single line game).

Quote: RS

If I'm understanding this correctly, the cycle for the 243 line game will be a large number....and the Hz for such a game would likely be very low (compared to a single line game).

So can I say the cycle for 243 way game is 243*(cycle of 1-line game)?

No, the cycle is just the number of different possibilities for the reels. Unless you have variable reels, the cycle is the product of the reel lengths. The number of hits for any outcome, whether that outcome is worth zero or some positive number, is necessarily positive. When you're doing a full-game volatility calculation, the outcome for a wager is the total payback -- so for a single game, if you win on three different lines and win line pays of 40, 20, and 2 coins, you don't count three hits, you just count one hit of 62 coins.

Quote: MathExtremist

No, the cycle is just the number of different possibilities for the reels. Unless you have variable reels, the cycle is the product of the reel lengths. The number of hits for any outcome, whether that outcome is worth zero or some positive number, is necessarily positive. When you're doing a full-game volatility calculation, the outcome for a wager is the total payback -- so for a single game, if you win on three different lines and win line pays of 40, 20, and 2 coins, you don't count three hits, you just count one hit of 62 coins.

This sound like I did something wrong. So it is quite hard to calculate the volatility of 243 way games by using spreadsheet because it is not that easier to find the coinciding wins and hits. I am thinking writing a code is easier to do. Before I read your post, I try the following pseudo code

Set STD=0
Enumerate each possible screen
On current screen, find hits on each winning. For example, for 3 winnings on the screen (based on the way game rule),
we have hits and pays as (H1, P1), (H2, P2) and (H3, P3). We compute STD = STD + sum{ Hn*(Pn-RTP)^2/N}
End

where N is the cycle of the game (produce of length of each reel). Now STD = SQRT(STD).

But it seems that it does not work after reading your comment. I am thinking should I do the follow instead?

Enumerate each possible screen
On current screen, find total pay of all possible wins. E.g. for 3 winnings on the screen (based on the way game rule),
we have hits and pays as (H1, P1), (H2, P2) and (H3, P3). We compute STD = STD + [sum(Pn)-RTP]^2/N
End

Now STD = SQRT(STD)

If that what you mean?

Right, if you're doing a full-game calculation, you want to know how much the game pays for a given bet, not how much a single line pays. The single line calculation is usually doable from the info in the par sheet. The complete game typically needs to be iterated because that info isn't there. The exceptions tend to be games that don't have lines in the first place, like Buffalo or other similar games.

And just to make your actual code easier to read, don't call your interim variable STD. Call it VOL or something, and at the end, STD = SQRT(VOL).

Quote: MathExtremist

Right, if you're doing a full-game calculation, you want to know how much the game pays for a given bet, not how much a single line pays. The single line calculation is usually doable from the info in the par sheet. The complete game typically needs to be iterated because that info isn't there. The exceptions tend to be games that don't have lines in the first place, like Buffalo or other similar games.

And just to make your actual code easier to read, don't call your interim variable STD. Call it VOL or something, and at the end, STD = SQRT(VOL).

Thanks a lot. Learn something :)