Subject: Re: [boost] [random] seeding with arbitrary integers
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-10-20 21:35:46
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
> 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 engines state to 1, otherwise sets the engines 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk