On a mac there is a srandomdev(0) function that randomizes random(0) when I execute random again. (Does that make sense?) But on Linux I that function doesn't seem to exist, so before I go ahead and try to implement srandomdev(0) in my program I was wondering if there is a way to do this. Currently I just do srandom(random()) then random() but everytime I run the program I get the same results so it would be nice if I could somehow prevent that. My last solution would be to implement srandomdev() or somehow create my own random algorithm.
Thanks,
Kenneth
Psuedo Random Randomness...:lol:
- kenneth_phough
- Member
- Posts: 106
- Joined: Sun Sep 18, 2005 11:00 pm
- Location: Williamstown, MA; Worcester, MA; Yokohama, Japan
- Contact:
Re: Psuedo Random Randomness...:lol:
Of course it's always the same, the randomizer you're using to seed your randomzier isn't properly seeded itself (since it's the one you're seeding), so it always produces the same "random" seed value.
Since you're on Linux, you could get your seed value by reading from /dev/urandom, or /dev/random if you're paranoid.
You could also use reading from one of those as your randomizer, but that could perform too much system calls if you need lots of numbers.
You should maybe be prepared for those files not to exist though, as IIRC there are some oddball distros with different locations for stuff. In that case you could use the old trick of using the current time as the seed, but since that's not really random it's probably best used as a fallback only.
Since you're on Linux, you could get your seed value by reading from /dev/urandom, or /dev/random if you're paranoid.
You could also use reading from one of those as your randomizer, but that could perform too much system calls if you need lots of numbers.
You should maybe be prepared for those files not to exist though, as IIRC there are some oddball distros with different locations for stuff. In that case you could use the old trick of using the current time as the seed, but since that's not really random it's probably best used as a fallback only.
- kenneth_phough
- Member
- Posts: 106
- Joined: Sun Sep 18, 2005 11:00 pm
- Location: Williamstown, MA; Worcester, MA; Yokohama, Japan
- Contact:
You're supposed to seed your PRNG only once at the beginning of your program, so only if you actually start your program every 10 or 100 nanoseconds is the current time going to be insufficient, but if you do that, I think you've got worse problems to solve anyway.
edit: For encryption, you need to add more entropy to the system during the execution, but you can't use a seed that's easily guessed, (such as time), so the situation is much more complex anyway.
Also, with most PRNGs seeding the PRNG from it's own output will actually decrease entropy, so doing it is bad idea. The only common PRNG where this is not an issue is the classic linear congruent generator, when it's implement such that it returns the full state (that is, 32-bit state for a 32-bit return value), in which case seeding the last random number is basicly no-op (since the last value would have been used as a new seed anyway).
I'll leave it as an excersize to the reader to prove that it's impossible to design a PRNG for which srand(rand()) actually increases entropy.
Anyway, with random numbers it's important to ask yourself first: how random you need the values to be. For something like audio noise, the quality is more or less irrelevant (linear congruent is fine, speed is much more important). For stuff like simulation, you need high quality series on numbers, but it's actually a good thing if you can use the same seed several times (allowing you to repeat the same experiment).
For cryptography, you'd better forget about writing your own generator, as you not only need a high quality series, you also need to collect entropy from some unpredictable (external) source, and you must avoid leaking information about the generators internal state.
edit: For encryption, you need to add more entropy to the system during the execution, but you can't use a seed that's easily guessed, (such as time), so the situation is much more complex anyway.
Also, with most PRNGs seeding the PRNG from it's own output will actually decrease entropy, so doing it is bad idea. The only common PRNG where this is not an issue is the classic linear congruent generator, when it's implement such that it returns the full state (that is, 32-bit state for a 32-bit return value), in which case seeding the last random number is basicly no-op (since the last value would have been used as a new seed anyway).
I'll leave it as an excersize to the reader to prove that it's impossible to design a PRNG for which srand(rand()) actually increases entropy.
Anyway, with random numbers it's important to ask yourself first: how random you need the values to be. For something like audio noise, the quality is more or less irrelevant (linear congruent is fine, speed is much more important). For stuff like simulation, you need high quality series on numbers, but it's actually a good thing if you can use the same seed several times (allowing you to repeat the same experiment).
For cryptography, you'd better forget about writing your own generator, as you not only need a high quality series, you also need to collect entropy from some unpredictable (external) source, and you must avoid leaking information about the generators internal state.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.