A Super Tiny Random Number Generator
blog.demofox.org
A Super Tiny Random Number Generator
1–7 of 7 posts
Re: A Super Tiny Random Number Generator
#2I used this small code snippet to produce 1M ints into a file and threw dieharder on the file, and while one run said one test was WEAK, the second run (on another machine) said the output PASSED all tests, so indeed it seems to be a decent PRNG, as far as small testing can tell.
Quite interesting for such a small subroutine.
Re: A Super Tiny Random Number Generator
#3I used this small code snippet to produce 1M ints into a file and threw dieharder on the file, and while one run said one test was WEAK, the second run (on another machine) said the output PASSED all tests, so indeed it seems to be a decent PRNG, as far as small testing can tell. Quite interesting for such a small subroutine.
The code snippet seems incomplete though. Seed is set, but is never used during the generation. I must admit I'm not all too familiar with C, but it doesn't seem to make much sense, unless there is something going on under the hood that doesn't stand out?
Re: A Super Tiny Random Number Generator
#4I used this small code snippet to produce 1M ints into a file and threw dieharder on the file, and while one run said one test was WEAK, the second run (on another machine) said the output PASSED all tests, so indeed it seems to be a decent PRNG, as far as small testing can tell. Quite interesting for such a small subroutine.
The code snippet seems incomplete though. Seed is set, but is never used during the generation. I must admit I'm not all too familiar with C, but it doesn't seem to make much sense, unless there is something going on under the hood that doesn't stand out?
It's used in GenerateRandomBit? (It's a global variable, almost certainly a bad idea for a general purpose random generator, though it'd probably be fine if it were _Thread_local)
Re: A Super Tiny Random Number Generator
#5Earlier quoted context omitted.
The code snippet seems incomplete though. Seed is set, but is never used during the generation. I must admit I'm not all too familiar with C, but it doesn't seem to make much sense, unless there is something going on under the hood that doesn't stand out?
It's used in GenerateRandomBit? (It's a global variable, almost certainly a bad idea for a general purpose random generator, though it'd probably be fine if it were _Thread_local)
True, but that's just used at if(GenerateRandomBit()) where it doesn't get stored, so I don't understand how dataPointer would have anything other than the zeros it has from the memset(&value, 0, sizeof(T)) call.
Re: A Super Tiny Random Number Generator
#6Earlier quoted context omitted.
It's used in GenerateRandomBit? (It's a global variable, almost certainly a bad idea for a general purpose random generator, though it'd probably be fine if it were _Thread_local)
True, but that's just used at if(GenerateRandomBit()) where it doesn't get stored, so I don't understand how dataPointer would have anything other than the zeros it has from the memset(&value, 0, sizeof(T)) call.
GenerateRandomBit() either returns true or false depending on the seed (which gets updated with each call). If it returns true on the first iteration then dataPointer[0] will be OR'd with 1 (i.e. set to "1"), otherwise it will be left as 0. For the next iteration, dataPointer[0] is conditionally OR'd with 2 etc. (until iteration 32, where it starts updating dataPointer[1]).
Re: A Super Tiny Random Number Generator
#7Earlier quoted context omitted.
True, but that's just used at if(GenerateRandomBit()) where it doesn't get stored, so I don't understand how dataPointer would have anything other than the zeros it has from the memset(&value, 0, sizeof(T)) call.
GenerateRandomBit() either returns true or false depending on the seed (which gets updated with each call). If it returns true on the first iteration then dataPointer[0] will be OR'd with 1 (i.e. set to "1"), otherwise it will be left as 0. For the next iteration, dataPointer[0] is conditionally OR'd with 2 etc. (until iteration 32, where it starts updating dataPointer[1]).
Ahh, okay now I'm understanding what's going on. Only dataPointer[0] is used unless it's a double, which will cause the pointerIndex to increase to 1 once the first 32 bits are set. Otherwise char[] will flip any/all of the first 8 bits, while int[] and float[] will be flipped for up to 32 bits at dataPointer[0]. Thanks for the explanation!