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: Greg Landrum <greg.landrum@…> 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)

getvals.cpp (747 bytes ) - added by Greg Landrum <greg.landrum@…> 15 years ago.
Sample code to demostrate the problem

Download all attachments as: .zip

Change History (2)

by Greg Landrum <greg.landrum@…>, 15 years ago

Attachment: getvals.cpp added

Sample code to demostrate the problem

comment:1 by Steven Watanabe, 14 years ago

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.