[boost] Re: bug in random_number_generator ?

From: David Pearce (d.pearce_at_[hidden])
Date: 2003-03-06 10:19:37

Hey,

> As far as I can understand you are asking for a ranomized integer value
> in the range [0,n) (i.e. n exclusive). If randomizing bits is what you
> want, then the correct call is rgen(2), not rgen(1) (which basically
> mean asking for an integer between 0 and 0 which doesn't exist so the
> failure is expected). This may look counterintuitive to you, but you can
> easily implement your own version which does not subtract 1 from n if
> wanted.

"Function call f(N) N is positive. Returns a pseudo-random number of 
type Integer. [2] The return value is less than N, and greater than or 
equal to 0."

--Taken from the SGI STL webpage regarding the Random Number Generator 
concept.

Therefore, zero should be a valid result from rgen(1) as it is within 
the range [0,1). I accept there would be no valid result for rgen(0).

Furthermore, the SGI implementation of random_sample_n, which I admit is
an SGI extension, expects that rgen(1) will return 0.

Cheers,

Dave

> 
>> > random_number_generator rgen(...);
>> > cout << rgen(1) << endl; // causes assertion failure
>>
>>I encountered this problem when using random_number_generator in 
>>conjuction with the random_sample_n algorithm.
>>I have attached a simple patch which catches the case when the parameter 
>>is 1. If anyone can tell me whether this is a reasonable fix, I would be 
>>grateful.
>>
> 
> The patch fixes a case which is wrong in the first place, so my answer
> would be no :)
> 
> <snip>
> 
>>    result_type operator()(argument_type n) {
>>!     if(n == 1) { 
>>!       return 0;
>>!     } else {
>>!       return uniform_int<base_type>(_rng, 0, n-1)();
>>!     }
>>    }
>>  
> 
> Not that it matters, but the 'else' here is useless. Try avoiding
> unnecessary else clauses.
> 
> Regards,
> --
> Tarjei
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>