Show Posts
1
QB64 Discussion / Bad random numbers, or TIMER limitation...?
« on: October 25, 2021, 08:18:02 pm »
Hey guys...
Picture 6 horses in a race, using the TIMER function at the START and FINISH to calculate elapsed time. They finish with the following times (in seconds)...
Racer 1 31.30453
Racer 2 31.48992
Racer 3 31.50592
Racer 4 31.8607
Racer 5 32.23148
Racer 6 32.41687
Then picture 6 different horses in a race, but same distance as race 1. This time, the results (in seconds) are...
Racer 7 30.93375
Racer 8 30.94975
Racer 9 31.11914
Racer 10 31.30453
Racer 11 31.48992
Racer 12 31.50592
Note that Racer 11 and Racer 12 have EXACTLY the same times as Racer 2 and Racer 3. The fact that all 6 times are not the same is encouraging, but how on earth could two identical times be possible, let alone have it happen twice?
I have seen this happen over a series of races...duplicate times (but not duplicate places in finish) come up a LOT. For instance, the time 32.77441 has happened 6 times in 30 races. That just doesn't seem to be right.
I have used the RANDOMIZE (-TIMER) and RANDOMIZE (TIMER) functions within the program - the first is used to determine how far forward the horse moves (the maximum is 3 pixels, the minimum is 1 pixel, so in practice, thus the average is 2 pixels). The second is invoked after every horse has moved, to calculate a random-length system delay between each move. To me, this means a new seed is generated every single time the program accesses the routine used to create the delay, I then take the average of 100 random numbers, and use this as the delay..maybe I misunderstand this function.
Randomize (Timer)
L = 0
For J = 1 To 100
K = Rnd(1) / 1000
L = L + K
Next J
m = L / 10
_Delay (m)
Anyway, I get that over running a series of random numbers between 1 and 3 will average 2, and that if you do that constantly over the same distance, you will get very similar times to complete the race...but introducing that random delay should be enough to avoid timing duplication down to the 100,000th of a second, shouldn't it?
Picture 6 horses in a race, using the TIMER function at the START and FINISH to calculate elapsed time. They finish with the following times (in seconds)...
Racer 1 31.30453
Racer 2 31.48992
Racer 3 31.50592
Racer 4 31.8607
Racer 5 32.23148
Racer 6 32.41687
Then picture 6 different horses in a race, but same distance as race 1. This time, the results (in seconds) are...
Racer 7 30.93375
Racer 8 30.94975
Racer 9 31.11914
Racer 10 31.30453
Racer 11 31.48992
Racer 12 31.50592
Note that Racer 11 and Racer 12 have EXACTLY the same times as Racer 2 and Racer 3. The fact that all 6 times are not the same is encouraging, but how on earth could two identical times be possible, let alone have it happen twice?
I have seen this happen over a series of races...duplicate times (but not duplicate places in finish) come up a LOT. For instance, the time 32.77441 has happened 6 times in 30 races. That just doesn't seem to be right.
I have used the RANDOMIZE (-TIMER) and RANDOMIZE (TIMER) functions within the program - the first is used to determine how far forward the horse moves (the maximum is 3 pixels, the minimum is 1 pixel, so in practice, thus the average is 2 pixels). The second is invoked after every horse has moved, to calculate a random-length system delay between each move. To me, this means a new seed is generated every single time the program accesses the routine used to create the delay, I then take the average of 100 random numbers, and use this as the delay..maybe I misunderstand this function.
Randomize (Timer)
L = 0
For J = 1 To 100
K = Rnd(1) / 1000
L = L + K
Next J
m = L / 10
_Delay (m)
Anyway, I get that over running a series of random numbers between 1 and 3 will average 2, and that if you do that constantly over the same distance, you will get very similar times to complete the race...but introducing that random delay should be enough to avoid timing duplication down to the 100,000th of a second, shouldn't it?