Opened 15 years ago
Closed 14 years ago
#1856 closed Bugs (invalid)
minstd_rand returning different values in 1.35.0 than in 1.34.1
Reported by: | Owned by: | No-Maintainer | |
---|---|---|---|
Milestone: | Boost 1.36.0 | Component: | random |
Version: | Boost 1.35.0 | Severity: | Problem |
Keywords: | Cc: |
Description
After moving from boost 1.34.1 to 1.35.0 I have noticed that the sequence of values returned by the minstd_rand generator has changed. This sample code (included in the attachment) generates different values with 1.35.0 than it did with 1.34.x and 1.33.x:
typedef boost::minstd_rand rng_type; typedef boost::uniform_int<> distrib_type; typedef boost::variate_generator<rng_type &,distrib_type> source_type; rng_type generator(42u); unsigned int seeds[] = {12,23,42}; distrib_type dist(0,INT_MAX); source_type randomSource(generator,dist); for(unsigned int i=0;i<3;++i){ generator.seed(seeds[i]); std::cerr << seeds[i]; for(unsigned int j=0;j<5;++j){ unsigned int bit = randomSource(); std::cerr<<" "<<bit%1024; } std::cerr<<std::endl; }
Output with v1.35.0:
12 691 854 1010 690 696 23 444 337 394 1000 751 42 404 8 37 977 972
and with v1.34.1:
12 691 844 854 975 292 23 214 852 444 337 394 42 883 404 943 348 8
If I use the mt19937 generator instead of minstd_rand, the sequences are the same across versions. In the event it matters, I'm using g++ v4.1.3 on an Ubuntu Linux system.
Attachments (1)
Change History (2)
by , 15 years ago
Attachment: | getvals.cpp added |
---|
comment:1 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
The values returned by minstd_rand are the same for both versions. The difference is in uniform_int.
uniform_int didn't handle signed/unsigned issues correctly in 1.33.1. Debugging this test case with 1.33.1 shows that during the second iteration (which prints 854 or 844), for the comparison on uniform_int.hpp line 97
if(result <= _range)
result is 9bad7746 and _range is 7fffffff. Since both arguments are signed, the comparison returns true, which is incorrect.
So, I modified the test case to print out the actual values returned by uniform_int, and some of them are indeed negative.
The current behavior is correct, so I'm marking this as invalid.
Sample code to demostrate the problem