4 ms·
Why is the "random()" function in libraries always not very random? Why do I always have to use some other function for more random stuff? Shouldn't the poor im
by someone_here 16y ago
Why is the "random()" function in libraries always not very random? Why do I always have to use some other function for more random stuff? Shouldn't the poor implimentation be called "fast_random()" or something similar?
- sgift 16y agoPrinciple of least surprise. If programmers want a "good enough" random value they will try random() first. If you really have a need for a better random value (e.g. usable for strong cryptography) you can be assumed to already know that random() is not good enough and can be trusted to search for a better substitute.
- gjm11 16y ago> If you really have a need for a better random value ... you can be assumed to already know ... and can be trusted to search for a better substitute. Oh, if only that were true. "If all scientific papers whose results are in doubt because of bad rand()s were to disappear from library shelves, there would be a gap on each shelf about as big as your fist." (From Numerical Recipes, which ironically has given at least its share of bad advice on random number generation, though the latest edition isn't too bad. Actually, the quotation is from an earlier edition because the latest edition puts it more accurately but less concisely.) Well ... strictly speaking it's perfectly true that you can be assumed to know, and can be trusted to search for something better. The trouble that the assumption and the trust would be very unwise.
- zokier 16y agoI'd say that random() producing good pseudorandom numbers is less surprising than not. If programmers want a random number they will try random() first. If they find it's performance inadequate, they can then search for faster alternatives.
- sgift 16y agoIn theory you are correct, in practice it is more complicated. There is no such thing as a good pseudo-random number (good meaning good for all use cases), only good enough. For random() to be useful it has to be generate "good" number for the average programming task, but must be fast enough that the average task can use it. Both properties are in conflict and so programming language implementors have to balance them out.
- mturmon 16y agoI disagree with this. For non-cryptographic purposes, the Mersenne Twister is very pseudorandom, has a huge period, and is competitively fast. There are also related shift-register techniques that have these properties. The state of the art in PRNG's is still advancing, but it takes a fairly esoteric example to find a blind spot of the MT (if initialized properly, as wrappers should do). Way outside the "generate a random 512x512 bitmap" variety.
- jacobolus 16y agoWhich is why Python’s random.random() (and friends) all just use the Mersenne Twister, and programmers can happily use it for their Monte Carlo simulations (or whatever), blissfully ignorant of the details of PRNGs.
- JulianMorrison 16y agoIt's plenty random enough for non-cryptographic uses of randomness, like shuffling a music player.
- lutorm 16y agoIt's not clear that it's random enough for Monte Carlo simulations, non-cryptographic though they may be. IIRC the standard random() has a pretty dysmal sequence length.
- barrkel 16y agoMost standard random routines have a period of 2^32 or 31. What they don't usually have is random low order bits. They're often linear congruential generators, just a multiply and an add.
- someone_here 16y agohttp://cod.ifies.com/2008/05/php-rand01-on-windows-openssl-rand-on.html http://cod.ifies.com/2008/05/php-rand01-on-windows-openssl-r... No.