Subject: Re: [boost] [Bug Sprint][random] overload resolution for constructors/seed
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-06-03 16:14:55
Keith Jeffery wrote:
>> Fixing #351 and #2887 will silently change the meaning of the
>> constructor call above. It will also be difficult to emulate the
>> previous (documented) behavior. However, looking at the current
>> standard draft, the constructor that causes these problems is not
>> present, so the standard mersenne twister will have a well behaved
>> copy constructor. Also, only lagged_fibonacci_01, mersenne_twister,
>> and subtract_with_carry provide the offending constructor, so
>> Boost.Random is not consistent. I'd like to have the copy constructor
>> called. What do others think?
> I think the principal of least surprise dictates that it should be the copy constructor. Can't the current behavior be achieved with the following?
> boost::mt19937 prng1;
> boost::mt19937 prng2;
Yes, but it will be inefficient, because it has to seed
twice. I suppose that we don't expect to create many
PRNGs so this is acceptable. I'm certain that the "correct"
behavior is to call the copy constructor. The main
question is whether it is worth breaking backwards
>> When testing fixes, I found that rand48 behaves differently with an
>> int64_t seed than with an int32_t seed. According to the current
>> draft standard, they should be equivalent. Should rand48 be changed
>> or should I leave it alone?
> For the same reason as above, I think the behavior should be the same.
rand48 has a 32 bit return type, so
according to the draft standard the seed should be
static_cast<uint32_t>(x). The problem is that the
state is a 64 bit number, so we don't really like to throw
away the extra bits when given a uint64_t.
This is not so much an issue of least surprise as of
ease of testing and matching <random> (which
has diverged a fair amount from Boost.Random
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk