AHA, that would explain it. Yes, my reasoning was based on totally
incorrectly assumptions about its guts then;) Thanks for the correction.
Peter
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/com
Michael Williams wrote:
I don't think Don was saying to use many calls to RDTSC to generate a
single random number.
I think he meant do something like (FastBadRand() XOR RDTSC).
The first part has low quality low-order bits and the second part has
low quality high-order bits.
That was my exac
Michael Williams wrote:
I don't think Don was saying to use many calls to RDTSC to generate a
single random number.
I think he meant do something like (FastBadRand() XOR RDTSC).
The first part has low quality low-order bits and the second part has
low quality high-order bits.
I also intende
Regarding the time used by RDTSC:
From
http://smallcode.weblogs.us/2007/12/07/performance-measurements-with-rdtsc/
Intel and Agner Fog recommend measuring the overhead
of RDTSC function and subtracting it from your result.
The overhead is relatively low (150-200 clock cycles)
and it occurs in all
terry mcintyre wrote:
Regarding the time used by RDTSC:
From
http://smallcode.weblogs.us/2007/12/07/performance-measurements-with-rdtsc/
Intel and Agner Fog recommend measuring the overhead
of RDTSC function and subtracting it from your result.
The overhead is relatively low (150-200 clock cy
What you could do is XOR the RDTSC into the seed (or array or whatever
your RNG uses) at the beginning of each playout. That adds to the
chaos but doesn't slow it down much at all.
___
computer-go mailing list
computer-go@computer-go.org
http://www.comput
Zach Wegner wrote:
What you could do is XOR the RDTSC into the seed (or array or whatever
your RNG uses) at the beginning of each playout. That adds to the
chaos but doesn't slow it down much at all.
I like your idea. Yes, you could probably use a really fast simple RNG
and do this. A
Hi,
As mentioned before, Monte Carlo simulations in physics was my thesis
topic, and there we need REALLY good PRNGs or we see the effect in
the results.
There is always a tradeoff between fast and good. If the newer Mersine
Twister algorithms (which are very good) is too slow and you want to
te
Personally, I think that much of the "really high quality" issues are not
that important for MC Go right now. I think that other things like not
having a reasonable distribution function (which UCT does a remarkable
job of smoothing over) completely overwhelm the effects of a poor PRNG.
I agree
An interesting note from
http://en.wikipedia.org/wiki/Knuth_shuffle which
appears to be pertinent to Don's remarks about a
limited number of games:
Limited PRNG state space
An additional problem occurs when the Fisher-Yates
shuffle is used with a pseudorandom number generator:
as the sequence
That's very interesting and I believe it explains everything perfectly.
If I understand this correctly, my 4 billion possible seeds (I used a 32
bit seed) cannot produce 32 billion different games (against the same
deterministic opponent.) In my implementation there were also issues
with the lo
These shuffles are different than the one I used and attempted to
describe.
Cheers,
David
On 16, May 2008, at 12:55 PM, terry mcintyre wrote:
An interesting note from
http://en.wikipedia.org/wiki/Knuth_shuffle which
appears to be pertinent to Don's remarks about a
limited number of games:
I am having some difficulties deciding on a string management scheme which
copes gracefully with merging groups. A first glance for me this seems like it
is quite a slow operation akin to capture. The problem is how to have each
stone vertex know which chain record to look up for information. I
Carter:
It might help to look at the Orego code. In the doc directory,
there's a file called Board-data-structures-explained.pdf.
Orego's current board-handling data structures are basically a Java
"translation" of Lukasz Lew's Library of Effective Go Routines (EGO),
although I've gone to
Thanks for pointing to the existence of this document. It clarifies some things
about a conventional light playout UCT design(It also answered a question about
pseudo-liberties I guess they are equivalent to what I term |multi set
liberty|). From the code I gather Orego (thus libEgo) does update
Dear CGOS watchers, :)
Mogo-pr-4core is the public release (not big float) version of MoGo
and running on Intel Q9550, latest 45nm chip of Core2 micro
architecture with larger L2 cache (2 x 6MB), at 3.4 GHz (8.5
x 400MHz; overclocked from rated 2.83GHz) on ASUS
P5K-VM motherboard.
Its perform
16 matches
Mail list logo
