Random Numbers
It doesn't. It only produces pseudo-random numbers based on things such as the current time, current CPU usage, etc.
Some chipsets (i820 was the first) can produce truly random numbers by sampling thermal noise. As an alternative, the technique (*) used by modern Unix variants for /dev/random is cryptographically secure and can therefore be called random. (pseudo-RNGs may satisfy statistical tests for randomness, but they are often predictable after observing a few outputs)
* gather entropy from various sources such as keyboard input and network traffic; mix together in a pool via strong hash function; return bytes from this pool.
* gather entropy from various sources such as keyboard input and network traffic; mix together in a pool via strong hash function; return bytes from this pool.
However, it should be noted that in practical applications being able to generate predictable and repeatable pseudo-random number sequences is often desirable. For example, if you're debugging a piece of code or some other stochastic simulation it's nice to be able to reproduce the same input values over and over so that they become a constant rather than a variable. For cryptography, maybe it's not so good. Just don't want anyone thinking that pseudo-random isn't as "good" as truly random because they both have their places.
Also, in computer graphics you often need pseudorandom because you don't want procedural textures to be different each time. Practically "true" random is necessary mostly for cryptography, in fact i know of no other things that really can't use good pseudorandom number generator and need "true" randomness.
"Common" methods for "random" numbers:
1) Psuedo-RNG - complex mathematical forumla creates seemingly random numbers. Good for games, not so good for cryptography. (/dev/random on *nix?)
2) Psuedo-RNG + Noise - things like a sampling of network activity XORed against the PRNG. Little benifit except added cryptography strength (/dev/srandom on *nix? - can block if not enough data from the environment to sample)
3) Quantum RNG - things like sampling thermal noise, sampling photons against a 50% opaque surface - link for some examples. The most cryptographically secure.
1) Psuedo-RNG - complex mathematical forumla creates seemingly random numbers. Good for games, not so good for cryptography. (/dev/random on *nix?)
2) Psuedo-RNG + Noise - things like a sampling of network activity XORed against the PRNG. Little benifit except added cryptography strength (/dev/srandom on *nix? - can block if not enough data from the environment to sample)
3) Quantum RNG - things like sampling thermal noise, sampling photons against a 50% opaque surface - link for some examples. The most cryptographically secure.
You can ask the user to move the mouse about for a few seconds and pick (x,y) points at regular intervals.
Quote:Original post by Anonymous Poster
You can ask the user to move the mouse about for a few seconds and pick (x,y) points at regular intervals.
This is amazingly not random, actually. Many people will perform the exact same motions every single time they're asked to do so, resulting in almost identical results every time. This is highly undesirable.
CM
From the looks of the question, the OP just wants to know how some magical function could produce a seemingly random number?
It is typically implemented pretty much as follows.
It is typically implemented pretty much as follows.
long holdrand;void srand(long seed){ holdrand = seed;}short rand(){ return (short)((holdrand = holdrand * 214013 + 2531011) >> 16);}Quote:Original post by iMalc
From the looks of the question, the OP just wants to know how some magical function could produce a seemingly random number?
It is typically implemented pretty much as follows.Simple eh!long holdrand;void srand(long seed){ holdrand = seed;}short rand(){ return (short)((holdrand = holdrand * 214013 + 2531011) >> 16);}
Not really. I think the right shift by 16 bits causes this to be a bad one!
For instance, off hand I guess that this version of rand returns numbers which will almost surely end with 0x26. Instead of taking a mod you are doing a shift. Not the same thing. Taking the lower 16 bits would probably have been better. Though i admit, your code needs more analysis to claim that this one is not a good one :-)...
I think what IMalc wanted to refer to is a Linear Congruential Generator
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
