Re: [PATCH v3 1/2] compat: add a mkstemps() compatibility function

[Antriksh Pany <antriksh.pany@gmail.com>]

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@viscovery.net> 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
>
>