Dice Logic - What is the deal here?

[spudw2k]

So, I've got a very basic function to operate as a dice roll witch a dynamically size die based on the input parameter.

Func _DiceRoll($iDieSize)
    SRandom(@MSEC)
    Return Random(1, $iDieSize, 1)
EndFunc   ;==>_DiceRoll

I'm trying to add the result of a d4 and a d6 together.

It seems that using the SRandom function without a delay between dice rolls causes both dies to either both be odd or both be even, thus preventing any odd number results.  What gives?

ConsoleWrite("Always Even" & @CRLF)
For $iX = 1 to 5
    Local $iD4 = _DiceRoll(4)
    Local $iD6 = _DiceRoll(6)
    ConsoleWrite($iD4 & " + " & $iD6 & " = " & $iD4 + $iD6 & @CRLF)
    sleep(100)
Next

ConsoleWrite(@CRLF & "Not always even" & @CRLF)
For $iX = 1 to 5
    Local $iD4 = _DiceRoll(4)
    sleep(100)
    Local $iD6 = _DiceRoll(6)
    ConsoleWrite($iD4 & " + " & $iD6 & " = " & $iD4 + $iD6 & @CRLF)
Next

Func _DiceRoll($iDieSize)
    SRandom(@MSEC)
    Return Random(1, $iDieSize, 1)
EndFunc   ;==>_DiceRoll

Any suggestions that don't require using sleep to insert a delay?

 

edit: well , it seems if I both pull out the SRandom function and the sleep it works alright.  Still interested if anyone has an opinion.

For $iX = 1 to 5
    Local $iD4 = _DiceRoll(4)
    Local $iD6 = _DiceRoll(6)
    ConsoleWrite($iD4 & " + " & $iD6 & " = " & $iD4 + $iD6 & @CRLF)
Next

Func _DiceRoll($iDieSize)
    Return Random(1, $iDieSize, 1)
EndFunc   ;==>_DiceRoll

 

Edited September 4, 2019 by spudw2k

[Nine]

Well, without any testing I would assume that if you do not put a sleep like in your first attempt (always even), the seed should be the same (within a millisecond).  That would explain the similar results.  If you want to use seed, I suggest you use a hash of a GUID.

[SlackerAl]

Don't re-seed the RNG each time you use it (I'm excluding uses in cryptography / security here because there are issues of future state prediction from a known start point). The seed is setting the start-point/input-value for the RNG, which is really a predictable list of pseudo random numbers. You need a random seed initially so that you do not always generate the same sequence of pseudo random numbers, but if you re-seed using the same value (accidentally or otherwise), as Nine has pointed out, you are just restarting your list of pseudo random numbers at the same point.

Setting the seed to a known value is at its most useful if you want to use the repeatability of the pseudo random sequence to procedurally generate data that appears random, but is repeatable e.g. terrain within a game.

Setting it randomly once will prevent your application from always producing its "random" events in the same order. Although it's possible to see the same parts of the pseudo random numbers repeated, if the RNG range is sufficiently large, this should not be apparent to the user.

 

Edit: added the word "randomly" to a couple of places to avoid any confusion.

Edited September 5, 2019 by SlackerAl

[spudw2k]

@SlackerAl Understood.  Thanks for chiming in.  I was hoping to add some randomness to the pseudo-randomness by using a random seed (wrap you hear around that 😜 ) to afford some less predictability.  I noticed in the SRandom help article it said to use @SEC for random sequences, so I thought I'd get the benefit of additional randomness by re-seeding; but I guess ultimately it's not important for my needs,

[RTFC]

Various AutoIt examples of calling a true random number generator can be found in this thread (see esp. AndyG's example); google TRNG for more info.