

************* ************* ************** ** ***** *********** ******* ************ ************* ********** 


********** ********** ********* ********** ********** ********* ********* ********* ********* ********** 
Geckoo wrote: 

May I say that with a very big amount of processes (x billions) I could have a really flat output ? 


LLN test with 100 coins Heads > 53 Tails > 47 Dispersion % : 12.766 LLN test with 10000 coins Heads > 5022 Tails > 4978 Dispersion % : 0.883889 LLN test with 1000000 coins Heads > 500246 Tails > 499754 Dispersion % : 0.0984484 


As you can understand, it generates a random number (Mersenne Twister 19937 generator) between two integers which I set in as a pair. It works as expected  and when "I throw my dice" 100 times, I have a real randomized output which I display this way showing numbers occurrences for 100 generations :

10.0
:


Means after 1 samples: means[0] = 10.0000 means[1] = 6.0000 means[2] = 10.0000 means[3] = 7.0000 means[4] = 10.0000 means[5] = 8.0000 means[6] = 14.0000 means[7] = 14.0000 means[8] = 14.0000 means[9] = 7.0000 Means after 999984 samples: means[0] = 9.9994 means[1] = 10.0041 means[2] = 9.9965 means[3] = 9.9978 means[4] = 9.9996 means[5] = 9.9962 means[6] = 10.0023 means[7] = 10.0016 means[8] = 10.0008 means[9] = 10.0018 [...] Means after 2372959660 samples: means[0] = 9.9999 means[1] = 9.9999 means[2] = 10.0000 means[3] = 10.0000 means[4] = 10.0001 means[5] = 10.0000 means[6] = 9.9999 means[7] = 10.0001 means[8] = 10.0000 means[9] = 10.0000 
100 / 10 = 10
George P wrote: 

use the same seed and you get the same sequence of numbers 
George P wrote: 

C++ has an embarrassment of riches for generating random numbers. 


Pseudo random Generator Number : 2 Number : 10 Number : 8 Number : 3 Number : 1 Number : 6 Number : 3 Number : 7 Number : 0 Number : 0 
UINT32_MAX
(or UINT64_MAX
), then using the modulo function (%
) to map those numbers to the 0 to N1
range is fine – as long a N is significantly smaller than UINT32_MAX
.UINT32_MAX
, and if UINT32_MAX
is not an exact multiple of N, then there will be a certain "bias", yes. But, again, as long as your N is significantly smaller than UINT32_MAX
, you don't have to worry about the bias, as the bias would be negligible.pseudo_rand()
give the exactly same result, because the clock has not advanced in between these calls! Keep in mind that the clock has a limited resolution and only "ticks" every so often!




kigar64551 wrote: 

Your problem here is a different one: The clock (seconds elapsed since "epoch") is not even close to being a "random" source !!! 


Number : 460923 Number : 479778 Number : 484588 Number : 488453 Number : 491815 Number : 496048 Number : 500407 Number : 504606 Number : 508759 Number : 513074 
Number : 633083 Number : 649724 Number : 651975 Number : 653616 Number : 655477 Number : 657054 Number : 658610 Number : 659978 Number : 662026 Number : 663529 
Number : 969272 Number : 987384 Number : 989496 Number : 990778 Number : 992479 Number : 993877 Number : 995210 Number : 996550 Number : 997887 Number : 999910 
rand() % N
would work a lot better than your time_since_epoch().count() % N
😏