8 ms·

Principle 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

by sgift 16y ago

Principle 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 ago
I'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 ago
  In 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 ago
    I 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 ago
      Which 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.

by sgift 16y ago

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 ago

I'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 ago
In 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 ago
  I 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 ago
    Which 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.