From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-04-16 10:00:08
"Jens Maurer" <Jens.Maurer_at_[hidden]> wrote in message
>Please bear in mind that there are two different "kinds" of random
>number engines: pseudo and non-deterministic ones.
you're right that I didn't thought of those in the beginning.
>> For the client a random number generator is just a black box that returns
>> some numbers. The client doesn't care
>> if there is an internal state change or if all the random sumbers are
>> precalculated in some húge array (bad example :-), but then there
>> be any state change). The client just uses it to get some numbers.
>People doing serious simulations certainly don't regard random numbers
>as a black box. The need to know as much as possible about the
>structure of the "black box". Please read the WG21 proposal at
>for some additional considerations.
ok, so for pseudo random number generators, there is by defiition a state
But the article don't discuss const vs non-const operator()(), does it?
>> Are we not making it harder for clients of the library? I think so.
>I think it is bearable for any user of Boost.Random to be
>aware of the basic functioning of a pseudo-random number
>generator (changes local state when you call operator())
>and take the appropriate action (add "mutable" to the random
>number engine object) if he really wants to put it in a const
OTOH, wouln't it be bearable for those who want's a reliable sequence
not to use the same generator object from several unrelated functions?
This could be completely enforced by using a local object.
Moreover, will this ever be a concern unless we have several threads
same random number generator? And even then? I guess I could really use some
motivating examples where one will need the non-const behavior, and I don't
think it's fair I should
come up with them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk