Re: [boost] boost::random overflow bug

From: Cromwell Enage (sponage_at_[hidden])
Date: 2004-08-23 16:51:37

Hello, Samuel.

[snip math]

> so in the end, most of the time when range==max,
> limit is assigned the value: range/(brange+1)
> instead of (range+1)/(brange+1).  So it cancels out
> the first bug most of the time (maybe that is the
> reason for the bizarre code).

Don't you just love obfuscated math?

> but the limit will still be equal to
> (range+1)/(brange+1) for brange=1 (I'm not sure how
> useful a coin-flipper generator would be, but we
> never know..),

A while back I implemented a random-path graph
algorithm that calculates a random "next vertex" or
"successor" during each step in the path.  Successor
candidates that cause U-turns or cycles are thrown out
before the random number generator is called.  If each
vertex has exactly three neighbors (e.g. when the
graph represents a buckyball wireframe), then the
random number generator degenerates into a
coin-flipper generator.  So it's not that farfetched.

> and mult can then be made to wrap and reach 0 in the
> previous loop, which loops forever.

I'll test your theory when I get the chance.

                              Cromwell Enage

                
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush