
Boost : 
From: Cromwell Enage (sponage_at_[hidden])
Date: 20040823 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 coinflipper generator would be, but we
> never know..),
A while back I implemented a randompath graph
algorithm that calculates a random "next vertex" or
"successor" during each step in the path. Successor
candidates that cause Uturns 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
coinflipper 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk