AMDG Robert Ramey wrote:
This sounds like the functions in question will silently alter the seed so that it "just works".
If this is what it is, I should say I don't like it. This means that if I do something invalid (a bad seed), I never find out about it. I would much prefer that if I pass an invalid parameter, I get either an return error code or an exception. Of course this is a pain as I have to go to the manual and figure out what I'm doing wrong. But it's much better than trying discover at some later time that things weren't doing what I thought they were.
I checked (a slightly dated) working draft and it looks the the standard does this kind of fixing up. explicit linear_congruential_engine(result_type s = default_seed); Effects: Constructs a linear_congruential_engine object. If c mod m is 0 and s mod m is 0, sets the engine’s state to 1, otherwise sets the engine’s state to s mod m. I guess the question is: what does the seed represent? It's only the initial state for the simple generators like linear_congruential etc. Since in general, seed applies some algorithm to generate the state from the seed, I don't see why the algorithm shouldn't be defined in such a way that any seed is valid.
It's also a pain that this means that the documentation has to be updated to explain why some seeds are not valid. But, that should already be in there.
The problem came up with lagged_fibonacci. There's no good reason, IMHO for lagged_fibonacci to reject any seed, since the state of a lagged_fibonacci generator is much larger than an int. On the other hand, it would be better if the seeding algorithm for lagged fibonacci never allowed distinct seeds to result in the same state. In Christ, Steven Watanabe