Re: 32 bit random numbers
>>Rob also said that, in theory, concatenation would be nice. The problem is
>>> concatenating adjacent random numbers, because the random generator is
>>> actually deterministic. For this reason, only 216 among all possible 232
>>> integers will be generated.
>
>
> Maybe not all possible 232 integers will be generated, but why exactly
> 216? Also, when using the fancy code in combination with set_rand()
> that Derek posted, no *adjacent* random numbers are concatenated.
>
> My text that you quoted above, was a reply to Pete, when he wrote:
> "As I think was said, I would also have noted that #00010001, #00020002,
> etc will be less likely."
> Sorry, I still don't see the reason why e.g. #00010001 would be less
> likely than any other value, when concatenating 2 uniformly distributed
> 16-bit random numbers.
>
> <snip>
>
> Regards,
> Juergen
One solution posted before was to take two successive rand(65536) and
concatenate the two 16-bit results to yield a 32-bit number. Al Getz just
posted this as well.
If the random seed does not change between the two calls to rand(), there's a
function, say f, that gives you the second number from the first. Hence the
intuitive approach only generates numbers of the form f(x):x, where f is the
above function, and x is any two byte integer. That's 2^16 numbers exactly.
This is the reason why using set_rand() between the two invocations is
important, as Derek pointed out. The value of the new rand seed should be as
disconnected from the previous rand() run as it can.
Regards
CChris
|
Not Categorized, Please Help
|
|
