5 ms·

> rand() is specified to always be seeded the same way. > For reasons I can’t fathom, the C standard mandates that rand() must always start as if it were seede

by elihu 9y ago

> rand() is specified to always be seeded the same way. > For reasons I can’t fathom, the C standard mandates that rand() must always start as if it were seeded with 1. I can’t imagine why anyone thought that was a good idea. What is the sense of making a random number facility that – by default – isn’t random? This seems like a good decision to me. There are plenty of use cases for arbitrary values that are consistent across runs (for instance, repeatable unit tests). If the application calls for non-determinism, let the application author do it themselves from an appropriate seed value. (I maybe somewhat biased from my experiences threading random number generator state in Haskell programs.)

int_19h 9y ago
I would argue the opposite - while there are many cases where you want values to be consistent across runs, I don't think they're the majority of the casual use of rand(). And especially for something that has "random" right there in the name, it is a very strange and counter-intuitive default. Furthermore, even for those cases where you do want consistency, I doubt you'd want a hardcoded seed value. Most of such cases allow the seed to be parametrized between runs without recompiling (via command line arguments, configs etc), and so they'll still need to invoke srand to set the seed. On the other hand, saying that without srand, the default is random, would actually allow modern implementations to e.g. initialize from /dev/random. Right now there's basically no cross-platform way to set a truly random seed in ISO C.
detaro 9y ago
> If the application calls for non-determinism, let the application author do it themselves from an appropriate seed value. It would be helpful if the c standard included a source for an appropriate seed value if that's the policy (which I think is wrong, given the naming it should be on those wanting reproducible behavior to flip a switch or set a fixed seed. Slow default is better than insecure default)

by elihu 9y ago

int_19h 9y ago

I would argue the opposite - while there are many cases where you want values to be consistent across runs, I don't think they're the majority of the casual use of rand(). And especially for something that has "random" right there in the name, it is a very strange and counter-intuitive default. Furthermore, even for those cases where you do want consistency, I doubt you'd want a hardcoded seed value. Most of such cases allow the seed to be parametrized between runs without recompiling (via command line arguments, configs etc), and so they'll still need to invoke srand to set the seed. On the other hand, saying that without srand, the default is random, would actually allow modern implementations to e.g. initialize from /dev/random. Right now there's basically no cross-platform way to set a truly random seed in ISO C.

detaro 9y ago

> If the application calls for non-determinism, let the application author do it themselves from an appropriate seed value. It would be helpful if the c standard included a source for an appropriate seed value if that's the policy (which I think is wrong, given the naming it should be on those wanting reproducible behavior to flip a switch or set a fixed seed. Slow default is better than insecure default)