
AMDG I've nearly finished preparing Boost.Random for the next release. Here's a summary of the changes. I still have some minor clean-up, but it's mostly stable. I'd greatly appreciate it if anyone wants to take a look at it. If you have issues with any of this, speak up now, while it can still be changed relatively painlessly. * Synchronized with the new standard. - Many new distributions added: chi_squared_distribution, negative_binomial_distribution, fisher_f_distribution, student_t_distribution, weibull_distribution, extreme_value_distribution, discrete_distribution, piecewise_constant_distribution, piecewise_liear_distribution - Renamed uniform_int and uniform_real to uniform_int_distribution and uniform_real_distribution. - Added members to all distributions: param_type, param, stream operators, comparison operators, min and max. - Allow distributions to be used directly with generators without use of variate_generator. - Changed the meaning of the parameters of geometric_distribution and lognormal_distribution. - Added a second parameter to gamma_distribution. - Added seed_seq and added the corresponding constructors and seed overloads the generators. - Added generate_canonical. - Renamed the engine tempates. e.g. mersenne_twister becomes mersenne_twister_engine. - New engine adapter independent_bits_engine. - Added new predefined engine typedefs: mt19937_64, ranlux[24|48][_base], knuth_b. - Updated seeding algorithms. - Added discard - Use unsigned types instead of signed types in all the predefined engines. * Bug fixes: - linear_congruential_engine could assert because the modular arithmetic was not implemented in all cases. shuffle_output, now called shuffle_order_engine, could cause integer overflow. These cases were not triggered by any predefined engines. - uniform_small_int now actually behaves as documented. * New efficient algorithms for binomial_distribution and poisson_distribution. * Moved all features into namespace boost::random * Complete rewrite of the tests - Use Boot.Test's automatic registration and make better use of its test tools. - Statistical tests of the distributions - Separate tests for each engine and distribution Backwards compatibility issues: * The seeding algorithms have changed. This was unavoidable for compatibility with the standard. Not to mention that some of the existing algorithms were weird and inconsistent. - Seeding with an integer: The behaviour should be unchanged for most generators except lagged_fibonacci and subtract_with_carry (and thus ranlux). - Seeding a generator with another generator: This has been enabled by making all all generators models of SeedSeq. Therefore, if you seed a Boost.Random generator with a non Boost.Random generator, your code will no longer compile. The algorithm has changed, so code using this seeding method will yield different values. - Seeding a generator from a pair of iterators: This implicitly assumed that the elements were 32-bit integers in some places, but not everywhere. I've added this requirement everywhere and updated the algorithms accordingly. The behaviour of generators with a value_type no more than 32 bits should be unchanged, but I have not verified this. I've added tests to make sure that the algorithms can't be changed accidentally. * Renaming: - Whenever I renamed a class, I provided a wrapper with the old name. There are also using declarations in namespace boost for everything that I moved. - The names of a few accessors in the distributions changed. I left both the old and the new names in place. * geometric_distribution and lognormal_distribution: - The behaviour is different at runtime. boost::geometric_distribution and boost::lognormal_distribution provide the old behaviour, boost::random::geometric_distribution and boost::random::lognormal_distribution provide the new behaviour. * Streaming: gamma_distribution has a new parameter, thus text saved with the old version will not readable by the new version. I haven't tried to deal with this. do people consider this important? * variate_generator: variate_generator is now a simple pass through wrapper. Code that assumes that it will adjust the generator's result type to match the distribution will no longer work. This is not an issue with any of the distributions provided by Boost.Random. * Return types: The result_types of some generators have changed slightly. Hopefully no one is depending on it being int instead of unsigned... * has_fixed_range: - This is now always false, as it doesn't appear to be very useful and is excessively cumbersome. Anything that was accessing const_min and const_max without first checking has_fixed_range was incorrect to begin with. I think that covers the breaking changes. If there's anything else, it's probably a bug, and I'll try to fix it. A few thing I know about, but haven't changed: * lagged_fibonacci comparison is not technically correct. It's possible for operator== to return false in some cases where the generators will actually produce identical (infinite) sequences. The probability that this will ever actually happen is very small. (As in 2^{-20000} for lagged_fibonacci607) * Similarly the textual representation of lagged_fibonacci is inconsistent with that used by the mersenne_twister and subtract_with_carry. Changing this would make old records unreadable. In Christ, Steven Watanabe

On 3/17/2011 11:47 AM, Steven Watanabe wrote:
AMDG
I've nearly finished preparing Boost.Random for the next release. Here's a summary of the changes. I still have some minor clean-up, but it's mostly stable. I'd greatly appreciate it if anyone wants to take a look at it. If you have issues with any of this, speak up now, while it can still be changed relatively painlessly. [...]
Are the old classes and interfaces officially deprecated, then? I would guess that the documentation will have migration information to update client code to use the new classes, interfaces, etc.? I don't use Boost.Random other than generating uniform random floats/doubles at the moment, so no issues here :/ - Jeff

AMDG On 03/17/2011 12:41 PM, Jeffrey Lee Hellrung, Jr. wrote:
On 3/17/2011 11:47 AM, Steven Watanabe wrote:
I've nearly finished preparing Boost.Random for the next release. Here's a summary of the changes. I still have some minor clean-up, but it's mostly stable. I'd greatly appreciate it if anyone wants to take a look at it. If you have issues with any of this, speak up now, while it can still be changed relatively painlessly. [...]
Are the old classes and interfaces officially deprecated, then?
Once it's released, yeah. They'll stay around for a while though.
I would guess that the documentation will have migration information to update client code to use the new classes, interfaces, etc.?
For the most part, I expect the changes to user code to be * Use boost::random::xxx instead of boost::xxx The bulk of the changes just add new features.
I don't use Boost.Random other than generating uniform random floats/doubles at the moment, so no issues here :/
In Christ, Steven Watanabe

I've nearly finished preparing Boost.Random for the next release. Here's a summary of the changes. I still have some minor clean-up, but it's mostly stable. I'd greatly appreciate it if anyone wants to take a look at it. If you have issues with any of this, speak up now, while it can still be changed relatively painlessly.
* Synchronized with the new standard. - Many new distributions added: chi_squared_distribution, negative_binomial_distribution, fisher_f_distribution, student_t_distribution, weibull_distribution, extreme_value_distribution, discrete_distribution, piecewise_constant_distribution, piecewise_liear_distribution
Both the Rayleigh distribution and it's generalization, the Rician distribution, don't appear to be supported and would be nice to have. I think they are not too hard to implement. Matthias

AMDG On 03/17/2011 01:05 PM, Matthias Schabel wrote:
* Synchronized with the new standard. - Many new distributions added: <snip> Both the Rayleigh distribution and it's generalization, the Rician distribution, don't appear to be supported and would be nice to have. I think they are not too hard to implement.
Sure, /after/ what I've already done is released. I'm only doing bug-fixes until then. In Christ, Steven Watanabe

On Thu, 17 Mar 2011 11:47:36 -0700, Steven Watanabe <watanabesj@gmail.com> wrote: <snip>
* Renaming: - Whenever I renamed a class, I provided a wrapper with the old name. There are also using declarations in namespace boost for everything that I moved. - The names of a few accessors in the distributions changed. I left both the old and the new names in place.
Are you/is there a way to notify, preferably at compile time, that said wrappers and old names are deprecated or are going to be deprecated?
A few thing I know about, but haven't changed: * lagged_fibonacci comparison is not technically correct. It's possible for operator== to return false in some cases where the generators will actually produce identical (infinite) sequences. The probability that this will ever actually happen is very small. (As in 2^{-20000} for lagged_fibonacci607)
Will this also be noted in the documentation? Thanks for all the hard work, Mostafa

AMDG On 03/17/2011 04:50 PM, Mostafa wrote:
On Thu, 17 Mar 2011 11:47:36 -0700, Steven Watanabe <watanabesj@gmail.com> wrote:
<snip>
* Renaming: - Whenever I renamed a class, I provided a wrapper with the old name. There are also using declarations in namespace boost for everything that I moved. - The names of a few accessors in the distributions changed. I left both the old and the new names in place.
Are you/is there a way to notify, preferably at compile time, that said wrappers and old names are deprecated or are going to be deprecated?
Good point. If I wrap them in #ifndef, BOOST_RANDOM_NO_DEPRECATED, I can use it hide them from doxygen as well.
A few thing I know about, but haven't changed: * lagged_fibonacci comparison is not technically correct. It's possible for operator== to return false in some cases where the generators will actually produce identical (infinite) sequences. The probability that this will ever actually happen is very small. (As in 2^{-20000} for lagged_fibonacci607)
Will this also be noted in the documentation?
No. It's not that hard to fix. I just made it a low priority because it's so unlikely to make a difference. In Christ, Steven Watanabe

Awesome, Steven; it's great to see this library progressing. Where does it stand in terms of compatibility with TR1/C++0x? I know that for a while they had drifted quite widely out-of-sync. On Fri, Mar 18, 2011 at 12:31 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 03/17/2011 04:50 PM, Mostafa wrote:
On Thu, 17 Mar 2011 11:47:36 -0700, Steven Watanabe <watanabesj@gmail.com> wrote:
<snip>
* Renaming: - Whenever I renamed a class, I provided a wrapper with the old name. There are also using declarations in namespace boost for everything that I moved. - The names of a few accessors in the distributions changed. I left both the old and the new names in place.
Are you/is there a way to notify, preferably at compile time, that said wrappers and old names are deprecated or are going to be deprecated?
Good point. If I wrap them in #ifndef, BOOST_RANDOM_NO_DEPRECATED, I can use it hide them from doxygen as well.
A few thing I know about, but haven't changed: * lagged_fibonacci comparison is not technically correct. It's possible for operator== to return false in some cases where the generators will actually produce identical (infinite) sequences. The probability that this will ever actually happen is very small. (As in 2^{-20000} for lagged_fibonacci607)
Will this also be noted in the documentation?
No. It's not that hard to fix. I just made it a low priority because it's so unlikely to make a difference.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams BoostPro Computing http://www.boostpro.com

AMDG On 03/18/2011 02:44 PM, Dave Abrahams wrote:
Awesome, Steven; it's great to see this library progressing. Where does it stand in terms of compatibility with TR1/C++0x? I know that for a while they had drifted quite widely out-of-sync.
I've tried to match the C++0x draft. To my knowledge the only remaining incompatibilities are: * I'm playing fast and loose with the integral types used. e.g. uint_least32_t instead of uint_fast32_t, or uintmax_t, instead of unsigned long long. * There is no typedef /unspecified/ default_random_engine. * A few constructors that take rvalue references are missing. rvalues will bind to const T& instead. In Christ, Steven Watanabe

On Fri, Mar 18, 2011 at 2:58 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 03/18/2011 02:44 PM, Dave Abrahams wrote:
Awesome, Steven; it's great to see this library progressing. Where does it stand in terms of compatibility with TR1/C++0x? I know that for a while they had drifted quite widely out-of-sync.
I've tried to match the C++0x draft. To my knowledge the only remaining incompatibilities are: * I'm playing fast and loose with the integral types used. e.g. uint_least32_t instead of uint_fast32_t, or uintmax_t, instead of unsigned long long.
Why? (just curious)
* There is no typedef /unspecified/ default_random_engine.
Why not? (ditto)
* A few constructors that take rvalue references are missing. rvalues will bind to const T& instead.
OK -- Dave Abrahams BoostPro Computing http://www.boostpro.com

AMDG On 03/23/2011 10:18 AM, Dave Abrahams wrote: > On Fri, Mar 18, 2011 at 2:58 PM, Steven Watanabe<watanabesj@gmail.com> wrote: >> On 03/18/2011 02:44 PM, Dave Abrahams wrote: >>> Awesome, Steven; it's great to see this library progressing. Where >>> does it stand in terms of compatibility with TR1/C++0x? I know that >>> for a while they had drifted quite widely out-of-sync. >> I've tried to match the C++0x draft. To my knowledge the >> only remaining incompatibilities are: >> * I'm playing fast and loose with the integral types used. >> e.g. uint_least32_t instead of uint_fast32_t, or uintmax_t, >> instead of unsigned long long. > Why? (just curious) I used uintmax_t, to avoid having to check BOOST_NO_LONG_LONG, uintmax_t should usually be unsigned long long anyway. Some experiments showed that using a 32-bit type for mt19937 could be faster than a 64-bit type, even when boost::uint_fast32_t was 64-bits. Other places, it was just because I wasn't being careful, or I never changed it from what it was originally. >> * There is no typedef /unspecified/ default_random_engine. > Why not? (ditto) No particular reason. I just didn't see a need for it. >> * A few constructors that take rvalue references are missing. >> rvalues will bind to const T& instead. > OK Of course, it doesn't really make a difference, since none of the generators have move constructors anyway... In Christ, Steven Watanabe
participants (5)
-
Dave Abrahams
-
Jeffrey Lee Hellrung, Jr.
-
Matthias Schabel
-
Mostafa
-
Steven Watanabe