Oh ok, didn't realize the sixth division was not used. In which case, we needn't have the sixth division. Also, 62^5 compared to 2^32 still gives a ~ 21% probability of the fifth division becoming zero, fairly high perhaps. The suggestion to change the code to ((uint64_t) tv.tv_usec) << 16) might help here. This would still leave about a 1.4% chance of v becoming zero, higher than (being pedantic!) what perfect randomness would require. Livable. But (just curious), do we see any loss in shifting a few more positions? - Antriksh On Tue, Jun 2, 2009 at 6:35 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > Antriksh Pany schrieb: >> 2. tv_usec has a decimal value range of 0-999999 (10^6 usec make 1 >> sec). Which means that tv_usec fits completely in 20 bits (or less). >> (tv_usec << 16) yields a number that fits completely in 36 bits (or >> less). Max value of this number is 999999 * 2^16, or for convenience, >> about M = 10^6 * 2^16. This number (in the range of 0 to M) goes on to >> be divided by D=62^6. Also, M > D. Thus, there is about a D / M * 100 >> ~ 87 % probability of the division M / D working out to be zero. i.e, >> in 87% cases, the last division (v/= num_letters) will cause 'v' to >> become 0. > > But this value (after the 6th division, mind you) is not used. v is used > the last time after the 5th division; at this time it still carries enough > randomness: 62^5 < 2^32. > > -- Hannes > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html