Thank you, Steve, for the insight here. I have removed the second RANDOMIZE and only triggering one RANDOMIZE (TIMER) at the beginning of the program. The goal of that 100-loop accumulation was simply to introduce a random delay on each sweep of the code that determines movement of the horses, because I am consistently getting identical times, which is really what I am asking about.
I agree 100 percent that the mean of a series of random numbers between 0 and .999999 approaches .5, and that loop wasn’t doing much, except that probably WASN’T exactly .5, and because _DELAY can use 1/1000ths, it should have been enough to prevent the identical times (to the 1/100000th) happening. It wasn’t.
I am not the most optimized coder, no question about that, but when I time events using TIMER, with that precision, I still cannot figure out how I am getting identical times all the way to the 1/100000th of a second. That should be, to my mind, quite impossible….or, since anything is possible, FAR less frequent.
There is too much code to paste here, but the gist of it is….
BEGIN
START RACE
StartTime = TIMER
Race is 1,440 pixels long
Begin Loop
Random numbers between 1 and 3 determine how many pixels forward each horse moves
All 6 horses move, in random order
All horses move forward
Eventually, each horse has moved 1,440 pixels (enough passes of 1, 2 or 3 have happened to add up to 1,440)
First horse crosses finish line
FirstTime = TIMER
FirstTime = FirstFinish - StartTime
Second horse crosses finish line
SecondFinish = TIMER
SecondTime = SecondFinish - TIMER
.
.
.
Sixth horse crosses finish line
SixthFinish = TIMER
SixthTime = SixthFinish - StartTime
End of loop
Race is done - display results
END
Sometimes, there are EXACT ties in a race. Dead heats happen in horse races, I have no issue with that, though, again, a tie to the 1/100000th of a second seems kind of wildly unlikely.
But run a few of these, and I get some identical times, all the way down to the 1/100000 of a second (I posted a list of 10 races x 6 times). The 4th place finisher in race #6 will have the identical time to the 2nd place finisher in race #3, for example. Again, to the 1/100000th of a second. That just should NOT happen.
I tried this. If I run a race where all horses move 3 pixels at a time, all 6 finish at basically the same time, but the first horse to move that last cycle wins by 2/100th of a second. Makes sense, there is processing time being used. However, all the other 5 horses have the exact same time down to the 5th decimal place. Something is strange about this type of thing.
From what you describe above, here's basically your program as best as I can reproduce it without the actual source:
RaceInSession = 0
steps = steps + 1
For i
= 0 To 5: Horse
(i
) = 0: FinishTimer
(i
) = 0:
Next RaceInSession = -1
Finished = -1
Horse
(i
) = Horse
(i
) + Int(Rnd * HorseSteps
) + 1 '1 to horsesteps per loop If FinishTimer
(i
) = 0 Then FinishTimer
(i
) = Timer - StartTime
Line (Horse
(i
) - 40, 50 * i
)-Step(40, 40), -1, BF
If FinishTimer
(i
) = 0 Then Finished
= 0
Now, as to WHY you're running into so many duplicated times, it's once again a process of AVERAGES in your program.
1440 pixels, with each horse taking a step from 1 to 3 pixels. That's an average of 720 steps for each horse,,,
This type of routine creates a BELL CURVE of probability, with the center values becoming much, much more likely to be the overall result of the running. For example, let's flip a coin 3 times... Our possible results are:
Head, head, head
head, head, tail
head, tail, head
head, tail, tail
tail, head, head
tail, head, tail
tail, tail, head
tail, tail, tail
Now, count heads as 0 and tails as 1 and what's your sums?
0
1
1
2
1
2
2
3
1 chance for 0, 3 chances for 1, 3 chances for 2, 1 chance for 3
You've created a bell curve such that the center values are much more likely to occur than the extreme values. The more times you flip a coin, the greater the extreme between the highest point of the bell curve and the lowest point of that same curve.
In 720 flips of a 3-sided coin, the central probability is going to occur with a quite likely chance. So much so, that you're ending up with horses which are finishing with basically equal times to their runs.
So how do we fix this type issue of averaging and bell curve probability?
Increase the range of each action and roll fewer dice overall.
100 coin flips is going to give you a number mighty damn close to 50, with little overall variance.
25 rolls of a four-sided dice is going to give a number mighty close to 50, but with a larger range of variance.
5 rolls of a twenty-sided dice is going to give a number somewhat close to 50, but with a MUCH larger range of variance.
1 roll of a hundred-sided dice would end up giving you an overall average of 50, but with an equally distributed variance from 1 to 100...
For the above, to change the number of steps and reduce the number of loops, all you have to do is change the value of the HorseSteps constant. Instead of 720 steps from 1 to 3 pixels, go for steps from 1 to 12 pixels, reducing the number of loops considerably, and spreading out the bell curve of your total times further apart in your program.
