From: Carlos Moreno on
Ulrich Eckhardt wrote:

>>>A more sophisticated way is to first determine the largest multiple of
>>>your range that is smaller or equal to RAND_MAX, call rand() until the
>>>value is
>>>in that range and then simply apply the modulo operator to the result.
>>
>>NO!!!!
>>
>>Do *NOT* use modulo for this sort of things [...]
>
> I don't get you.

*sigh* Join the club :-)

> I for sure did not say to use 'rand()%max_value', which
> introduces these uneven distributions and is therefore wrong

Indeed. That would have been *severely* wrong.

As pointed out already, the lower bits, for certain classes of
generators and certain implementations tend to have lower
"randomness" than the higher bits.

rand() tends to be one of those implementations in which the
above tends to be true.

The argument of using division instead of modulo goes like
this: if the RNG suffers from that defect [lower randomness
in the lower bits], then division is ok and modulo is not.
And if the RNG does not suffer at all from that defect, then
both [division and modulo] are equally good.

So, in some cases modulo is worse, and in no case division
is worse -- why use modulo then?

Carlos
--

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Ulrich Eckhardt on
Carlos Moreno wrote:
[using modulo versus using integer division to cut down an RNG's range]
> As pointed out already, the lower bits, for certain classes of
> generators and certain implementations tend to have lower
> "randomness" than the higher bits.
[snipped further explanation]
> So, in some cases modulo is worse, and in no case division
> is worse -- why use modulo then?

Okay, now that's a reasoning I accept!

However, I'd like to point out something: you implemented a workaround but
omitted to document what exactly it was you were working around. As you
already saw, someone else that read your code (in this case me) already
nullified your fix because he didn't know what the counterintuitive code
was supposed to fix.

Yes, I also sometimes think that everybody should know this or that...

Uli


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Pete Becker on
Carlos Moreno wrote:

>
> rand() tends to be one of those implementations in which the
> above tends to be true.
>

More accurately, it is frequently said that some implementations of
rand() have that problem.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Carlos Moreno on
Thomas Maeder wrote:

>>>the following mapping applies:
>>>0 -> 0
>>>1 -> 1
>>>2 -> 2
>>>3 -> 3
>>>4 -> 0
>>>5 -> 1
>>>6 -> 2
>>>7 -> 3
>>>8 -> reroll
>>>9 -> reroll
>>
>>Good, except that it should be:
>>
>>0 -> 0
>>1 -> 0
>>2 -> 1
>>3 -> 1
>>4 -> 2
>>5 -> 2
>>6 -> 3
>>7 -> 3
>>8 -> reroll
>>9 -> reroll
>
>
> If the numbers 0 to 7 occur with equal probability, I don't see a
> fundamental difference why your suggestion should be better.
>
> Care to elaborate?

See my reply to Ulrich in a sibling sub-thread.

Carlos
--

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Pete Becker on
kevin.hall(a)motioneng.com wrote:

> Though I believe the MT is less susceptible
> to having lower order bits be less random, I haven't yet seen a study
> that proves that. I would like to though -- seriously I would. If you
> can point me to one or to a study that proves that the lower order bits
> for the PRNGs that you use are not less random, please post a link.
>

Interesting: you ask for proof that other RNGs are good, but accept the
mersenne twister on faith.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]