Boost logo

Boost :

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


> 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

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.



>> > 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
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at