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