5 ms·
Backwards-compatibility should not be an issue here either. Is there any way to actually be dependent on the regularity of rand()?
by Scriptor 17y ago
Backwards-compatibility should not be an issue here either. Is there any way to actually be dependent on the regularity of rand()?
- gojomo 17y agoYes. Some applications want series of numbers that are pseudorandom, but completely reproducible, once you've provided the same seed. (See PHP's srand().) This is often the case with simulations, or other algorithms that have a 'random' component that you'd still like to hold constant across (for example) related runs during testing or across distributed machines. So there may be a sensible case for maintaining backward-compatible rand() behavior here, even though a better algorithm is available.
- tesseract 17y agoThen make srand = mt_srand.
- gojomo 17y agoThat doesn't resolve the problem for code relying on stable behavior of these functions. Given the following code... srand(CONSTANT); n = rand(); ...the scenarios I mentioned benefit from n being the exact same number in PHP version X and then version X+1, X+2, etc. If PHP swaps out both rand() and srand(), backward-compatibility is broken, and along with it some kinds of quite-reasonable code that relied on srand() initializing rand() to give the same deterministic stream of numbers (rather than just a deterministic stream). It might still be worth taking that hit -- I don't have a strong opinion -- but there are good reasons not to break backwards-compatibility, even to improve PRNG quality.