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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
