[computer-go] Aya weaker bots not MC
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/computer-go/
Re: [computer-go] Random
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 exact idea, to xor or add RDTSC to the results.If that
really is a slow operation then it basically kills the idea. The cycle
time should be published somewhere though.
- Don
Also, I can't imagine why executing a RDTSC would take 50 cycles. But
I couldn't find any docs on that aspect of the instruction.
steve uurtamo wrote:
the only thing to watch is that you'll likely need
30+ bits from these guys to seed a prng, and
getting those bits in any organized way is likely
going to happen on a regular schedule (i.e. if
you get them in a loop, you're likely going to
space them out in an organized way).
s.
On 5/15/08, Don Dailey <[EMAIL PROTECTED]> wrote:
For a long time I have pondered whether you could build a very high
quality
random number generator that was extremely fast using the pentium RDTSC
instruction as a low order bit entropy source. The idea would be
to use
an extremely fast (but low quality) pseudo random number generator,
but
modify the output (or the internal state of the generator) with the
time
stamp register at each call.
RDTSC reads the pentiums internal clock and is basically just a 64 bit
counter.However it increments very quickly and could be viewed
as an
entropy source in the lowest bits as it would introduce at least a
little
bit of non-determinism, and I think a little is all you would need to
transform a horrible generator into a good practical one for many
applications. I think the lowest 2 or 3 (or more) bits would
appear to
modern processors as almost unpredictable since there is so much
going on
inside modern computers that are unpredictable.
I don't know if the call to RDTSC is fast or how it would affect the
parallelism of todays modern machines. I'm not particularly
interested in
non-deterministic generators as I sometimes depend on this for
testing and
debugging, but it's an idea I thought I would throw out there.
- Don
Don Dailey wrote:
If you are looking for a cheap fast and simple random number
generator, A
post by George Marsaglia, an expert/guru on random number generation
has
several and a C implemention.
These are one line generators, coded as macros.He also
discusses the
period and quality of each of them. This is a gem of a post on
sci.stat.math,sci.math if you are interested in RNG:
http://www.math.niu.edu/~rusin/known-math/99/RNG
- Don
Heikki Levanto wrote:
In addition, xor_shift is better than builtin rand() and faster and
much smaller than MT.
I don't know that much about random numbers, so excuse my
ignorance. But
a
bit of googling got me to the Park - Miller Minimal Standard random
number
generator
http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf
>From what I read, it should be quite sufficient for go programs.
It is
dead simple and fast:
long int pmrand() {
const long int a=16807;
const long int m= ( 1 << 31 ) -1;
pmrandseed = ( pmrandseed * a ) % m ;
return pmrandseed;
} /* pmrand */
Should I worry about this not being good enough?
- Heikki
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 intended for RDTSC to change the state of the random number
generator which would be extremely chaotic over time. Some
FastBadRand() generators use the last value returned as the state.
- Don
Also, I can't imagine why executing a RDTSC would take 50 cycles. But
I couldn't find any docs on that aspect of the instruction.
steve uurtamo wrote:
the only thing to watch is that you'll likely need
30+ bits from these guys to seed a prng, and
getting those bits in any organized way is likely
going to happen on a regular schedule (i.e. if
you get them in a loop, you're likely going to
space them out in an organized way).
s.
On 5/15/08, Don Dailey <[EMAIL PROTECTED]> wrote:
For a long time I have pondered whether you could build a very high
quality
random number generator that was extremely fast using the pentium RDTSC
instruction as a low order bit entropy source. The idea would be
to use
an extremely fast (but low quality) pseudo random number generator,
but
modify the output (or the internal state of the generator) with the
time
stamp register at each call.
RDTSC reads the pentiums internal clock and is basically just a 64 bit
counter.However it increments very quickly and could be viewed
as an
entropy source in the lowest bits as it would introduce at least a
little
bit of non-determinism, and I think a little is all you would need to
transform a horrible generator into a good practical one for many
applications. I think the lowest 2 or 3 (or more) bits would
appear to
modern processors as almost unpredictable since there is so much
going on
inside modern computers that are unpredictable.
I don't know if the call to RDTSC is fast or how it would affect the
parallelism of todays modern machines. I'm not particularly
interested in
non-deterministic generators as I sometimes depend on this for
testing and
debugging, but it's an idea I thought I would throw out there.
- Don
Don Dailey wrote:
If you are looking for a cheap fast and simple random number
generator, A
post by George Marsaglia, an expert/guru on random number generation
has
several and a C implemention.
These are one line generators, coded as macros.He also
discusses the
period and quality of each of them. This is a gem of a post on
sci.stat.math,sci.math if you are interested in RNG:
http://www.math.niu.edu/~rusin/known-math/99/RNG
- Don
Heikki Levanto wrote:
In addition, xor_shift is better than builtin rand() and faster and
much smaller than MT.
I don't know that much about random numbers, so excuse my
ignorance. But
a
bit of googling got me to the Park - Miller Minimal Standard random
number
generator
http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf
>From what I read, it should be quite sufficient for go programs.
It is
dead simple and fast:
long int pmrand() {
const long int a=16807;
const long int m= ( 1 << 31 ) -1;
pmrandseed = ( pmrandseed * a ) % m ;
return pmrandseed;
} /* pmrand */
Should I worry about this not being good enough?
- Heikki
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 tested functions, so you can neglect it when measuring long functions (e.g., 100 000 clock cycles). NOTE: the page above recommends flushing the cache before calling RDTSC, when using it for timing purposes. There is probably no need to do so when grabbing LSBs. I wonder, however, if the LSBs would be as random as all that, when called frequently in quasi-deterministic code which takes a predictable number of cycles between invocations. Terry McIntyre <[EMAIL PROTECTED]> Wherever is found what is called a paternal government, there is found state education. It has been discovered that the best way to insure implicit obedience is to commence tyranny in the nursery. Benjamin Disraeli, Speech in the House of Commons [June 15, 1874] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 cycles) and it occurs in all tested functions, so you can neglect it when measuring long functions (e.g., 100 000 clock cycles). NOTE: the page above recommends flushing the cache before calling RDTSC, when using it for timing purposes. There is probably no need to do so when grabbing LSBs. I wonder, however, if the LSBs would be as random as all that, when called frequently in quasi-deterministic code which takes a predictable number of cycles between invocations. I'm not interested in using it here to measure performance, but as a possible way to have a very fast and very high quality random number function. But this won't happen if RDTSC isn't fast and it doesn't appear to be very fast. I don't expect RDTSC to be very random either, I'm more interested in the chaos it presents to the random number system which is produced even with very little agitation added to the system. Even an occasional 1 bit change would cure many of the problems of some fast random number generators. If you were to call this random number generator consecutively, many time in a tight loop, I suspect that you will get a LOT of variation in the number of cycles that have passed between calls, certainly enough to make it completely unpredictable in the long run. Like weather predictions you might predict the next day (or call) with some level of reasonable accuracy but not a specific day in the next month. Every deterministic pseudo random number generator in existence always has some kind of structure. The main difference between what we consider good and bad ones is how well that structure is obfuscated or hidden from view. We try to be clever so that statistical tests cannot see the structure. One of primary methods to "hide" this structure is to make it so big (by long cycle lengths) that we can only see a tiny portion of it. For instance if every zillion'th bit alternated between 0 and 1, it would be hard to observe. So if you can add a small amount of non-determinism you can probably "bust up" the hidden structure. At any rate, it seems like it's not workable as a fast alternative to RNG. It might be combined with a slow very high quality generator to produce numbers that are somewhat closer to true random numbers. - Don Terry McIntyre <[EMAIL PROTECTED]> “Wherever is found what is called a paternal government, there is found state education. It has been discovered that the best way to insure implicit obedience is to commence tyranny in the nursery.” Benjamin Disraeli, Speech in the House of Commons [June 15, 1874] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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. AnchorMan had a very trivial RNG and I noticed that if you played enough games, you start getting the same games over and over. So I could only play a few hundreds before this started happening (for instance playing anchor vs anchor.) It seems like with 4 billion possible seeds that this would not happen (each games started with a seed based on the time() call.) But apparently something was going on that I didn't understand because there seemed to be only a few hundred games possible (at any fixed level.) I switched over to Mersenne Twister and this problem went away. MT did not improve the playing quality in any way I could notice, so I don't believe MC in general requires a very good RNG. I once built a card playing program, and while developing a playing strategy I tested different versions against each other. But then I tried as a sanity check, testing the same version against itself, and I noticed a systematic bias, one particular side was winning something like 53 or 54 percent of the games even though the conditions were unbiased. I discovered the problem was with the RNG in the C library (this was a long time ago.)I solved the problem by changing the way I shuffled the cards.Originally I created a deck from scratch which always had the same ordering, then I would apply the standard Fischer-Yates shuffle. The fix was to reuse the deck from the last game and shuffle THAT deck. Basically I grabbed up all the cards in the players hands and on the "table" and put them back in the deck just like us humans do when playing cards, then I would shuffle them.The effect was that I implicitly created a more sophisticated RNG with lots of state and more than likely a very long cycle time compared to the simple one I started with. This could be done with your go program too. If you have some sort of list of all the legal points at the beginning of the game that you work with and manipulate, just leave it alone instead of reinitializing it.Or let the move sequences of the previous game impact the initial ordering or how the game is played.You would be getting a more sophisticated RNG for free. Of course you have to save state between program invocations and that's probably too ugly. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 test an alternative, you can use the trick that is in Knuth that I used for my thesis work. It is a 2 step generator that shuffles. You build an array that holds a set of PRNGs straight from your crude but very fast generator (I was partial to a list of 273), Your first PRNG call mod(arraysize) picks the PRN you will use, and then the second refills that spot. No promises that this is any faster, but for lattice simulations where any correlations pop right out at you sort of like a herringbone pattern, this shuffling worked great for me. 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. Cheers, David On 16, May 2008, at 10:42 AM, Don Dailey wrote: 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 cycles) and it occurs in all tested functions, so you can neglect it when measuring long functions (e.g., 100 000 clock cycles). NOTE: the page above recommends flushing the cache before calling RDTSC, when using it for timing purposes. There is probably no need to do so when grabbing LSBs. I wonder, however, if the LSBs would be as random as all that, when called frequently in quasi-deterministic code which takes a predictable number of cycles between invocations. I'm not interested in using it here to measure performance, but as a possible way to have a very fast and very high quality random number function. But this won't happen if RDTSC isn't fast and it doesn't appear to be very fast. I don't expect RDTSC to be very random either, I'm more interested in the chaos it presents to the random number system which is produced even with very little agitation added to the system. Even an occasional 1 bit change would cure many of the problems of some fast random number generators. If you were to call this random number generator consecutively, many time in a tight loop, I suspect that you will get a LOT of variation in the number of cycles that have passed between calls, certainly enough to make it completely unpredictable in the long run. Like weather predictions you might predict the next day (or call) with some level of reasonable accuracy but not a specific day in the next month. Every deterministic pseudo random number generator in existence always has some kind of structure. The main difference between what we consider good and bad ones is how well that structure is obfuscated or hidden from view. We try to be clever so that statistical tests cannot see the structure. One of primary methods to "hide" this structure is to make it so big (by long cycle lengths) that we can only see a tiny portion of it. For instance if every zillion'th bit alternated between 0 and 1, it would be hard to observe. So if you can add a small amount of non-determinism you can probably "bust up" the hidden structure. At any rate, it seems like it's not workable as a fast alternative to RNG. It might be combined with a slow very high quality generator to produce numbers that are somewhat closer to true random numbers. - Don Terry McIntyre <[EMAIL PROTECTED]> “Wherever is found what is called a paternal government, there is found state education. It has been discovered that the best way to insure implicit obedience is to commence tyranny in the nursery.” Benjamin Disraeli, Speech in the House of Commons [June 15, 1874] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 with that. By the way, I have spent time on the use of improved forms of Monte-Carlo (quasi-random, stratification, ...) but I've never found an efficient trick. OT ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 of numbers output by such a generator is entirely determined by its internal state at the start of a sequence, a shuffle driven by such a generator cannot possibly produce more distinct permutations than the generator has distinct possible states. Even when the number of possible states exceeds the number of permutations, the irregular nature of the mapping from sequences of numbers to permutations means that some permutations will occur more often than others. Thus, to minimize bias, the number of states of the PRNG should exceed the number of permutations by at least several orders of magnitude. For example, the built-in pseudorandom number generator provided by many programming languages and/or libraries may often have only 32 bits of internal state, which means it can only produce 232 different sequences of numbers. If such a generator is used to shuffle a deck of 52 playing cards, it can only ever produce a vanishingly small fraction of the 52! ≈ 2225.6 possible permutations. Thus, it's impossible for a generator with less than 226 bits of internal state to produce all the possible permutations of a 52-card deck, and for a (reasonably) unbiased shuffle, the generator must have at least about 250 bits of state. A further problem occurs when a simple linear congruential PRNG is used with the divide-and-take-remainder method of range reduction described above. The problem here is that the low-order bits of a linear congruential PRNG are less random than the high-order ones: the low n bits of the generator themselves have a period of at most 2n. When the divisor is a power of two, taking the remainder essentially means throwing away the high-order bits, such that one ends up with a significantly less random value. Also, of course, no pseudorandom number generator can produce more distinct sequences than there are distinct seed values it may be initialized with. Thus, it doesn't matter much if a generator has 1024 bits of internal state if it is only ever initialized with a 32-bit seed. The page also describes several other sources of bias which may be pertinent to the development of MC programs. Terry McIntyre <[EMAIL PROTECTED]> Wherever is found what is called a paternal government, there is found state education. It has been discovered that the best way to insure implicit obedience is to commence tyranny in the nursery. Benjamin Disraeli, Speech in the House of Commons [June 15, 1874] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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 lower ordered bits which of course are less random. - Don 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: Limited PRNG state space An additional problem occurs when the Fisher-Yates shuffle is used with a pseudorandom number generator: as the sequence of numbers output by such a generator is entirely determined by its internal state at the start of a sequence, a shuffle driven by such a generator cannot possibly produce more distinct permutations than the generator has distinct possible states. Even when the number of possible states exceeds the number of permutations, the irregular nature of the mapping from sequences of numbers to permutations means that some permutations will occur more often than others. Thus, to minimize bias, the number of states of the PRNG should exceed the number of permutations by at least several orders of magnitude. For example, the built-in pseudorandom number generator provided by many programming languages and/or libraries may often have only 32 bits of internal state, which means it can only produce 232 different sequences of numbers. If such a generator is used to shuffle a deck of 52 playing cards, it can only ever produce a vanishingly small fraction of the 52! ≈ 2225.6 possible permutations. Thus, it's impossible for a generator with less than 226 bits of internal state to produce all the possible permutations of a 52-card deck, and for a (reasonably) unbiased shuffle, the generator must have at least about 250 bits of state. A further problem occurs when a simple linear congruential PRNG is used with the divide-and-take-remainder method of range reduction described above. The problem here is that the low-order bits of a linear congruential PRNG are less random than the high-order ones: the low n bits of the generator themselves have a period of at most 2n. When the divisor is a power of two, taking the remainder essentially means throwing away the high-order bits, such that one ends up with a significantly less random value. Also, of course, no pseudorandom number generator can produce more distinct sequences than there are distinct seed values it may be initialized with. Thus, it doesn't matter much if a generator has 1024 bits of internal state if it is only ever initialized with a 32-bit seed. The page also describes several other sources of bias which may be pertinent to the development of MC programs. Terry McIntyre <[EMAIL PROTECTED]> “Wherever is found what is called a paternal government, there is found state education. It has been discovered that the best way to insure implicit obedience is to commence tyranny in the nursery.” Benjamin Disraeli, Speech in the House of Commons [June 15, 1874] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Random
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: Limited PRNG state space ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Another beginner question: string management
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 am curious how this is done in the current generation of MC bots. Is the naive way the best i.e. going through each stone and updating the pointer to the record? Regards, Carter. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Another beginner question: string management
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 somewhat greater length to explain them. If you find C++ easier to read than Java, by all means use Lew's code. Orego is here (you'll have to download and unpack the latest .jar): http://www.lclark.edu/~drake/Orego.html Peter Drake http://www.lclark.edu/~drake/ On May 16, 2008, at 4:29 PM, Carter Cheng wrote: 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 am curious how this is done in the current generation of MC bots. Is the naive way the best i.e. going through each stone and updating the pointer to the record? Regards, Carter. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Another beginner question: string management
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 all the pointers to the chain record. There are still a few design tradeoffs I dont quite understand such as caching adjacent vertex properties in the vertex. How much and why does this result in a speedup? Regards, Carter. --- On Fri, 5/16/08, Peter Drake <[EMAIL PROTECTED]> wrote: > From: Peter Drake <[EMAIL PROTECTED]> > Subject: Re: [computer-go] Another beginner question: string management > To: "computer-go" > Date: Friday, May 16, 2008, 4:39 PM > 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 somewhat greater length to > explain them. If you > find C++ easier to read than Java, by all means use > Lew's code. > > Orego is here (you'll have to download and unpack the > latest .jar): > > http://www.lclark.edu/~drake/Orego.html > > Peter Drake > http://www.lclark.edu/~drake/ > > > > On May 16, 2008, at 4:29 PM, Carter Cheng wrote: > > > 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 am curious > how this is > > done in the current generation of MC bots. > > > > Is the naive way the best i.e. going through each > stone and > > updating the pointer to the record? > > > > Regards, > > > > Carter. > > > > > > > > ___ > > computer-go mailing list > > computer-go@computer-go.org > > > http://www.computer-go.org/mailman/listinfo/computer-go/___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] mogo-pr-4core on cgos 9x9
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 performance is almost tie against mogo-big-4core but seems better to others. Somewhat interesting. -Hideki -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
