From: Cromwell Enage (sponage_at_[hidden])
Date: 2004-08-23 16:51:37
> 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.
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk