[computer-go] Michael Williams enhancement
I have empirical evidence that mwRefbot level 4096 (the Michael Williams enhanced reference bot at 4096 playouts) is stronger than the reference bot at the same (and even higher levels.) Rank Name Elo+- games score oppo. draws 1 mwRefbot-004096 2684 23 22 1529 78% 21400% 2 refbot-0081922670 21 21 1532 73% 22740% 3 refbot-0040962645 21 21 1528 71% 22510% 4 refbot-0020482555 21 21 1530 63% 22370% 5 refbot-0010242431 23 23 1529 54% 21780% 6 refbot-0005122253 27 28 1531 47% 20660% 7 refbot-0002562000 34 35 1529 42% 19320% 8 refbot-0001281646 42 42 1529 45% 16550% 9 refbot-641290 40 40 1529 50% 13210% 10 refbot-32 970 40 40 1531 52% 10410% 11 refbot-16 621 33 32 1529 55% 7800% 12 refbot-08 370 25 25 1529 47% 6490% 13 refbot-04 250 23 22 1529 43% 5510% 14 refbot-02 145 22 22 1529 35% 5000% 15 refbot-01 5 22 23 1528 22% 4750% 16 refbot-00 0 22 23 1531 22% 4840% - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] OT: Harder than go?
On Mon, 2008-10-27 at 23:23 -0400, Luke Gustafson wrote: > Computer Scrabble significantly exceeds humans. A basic monte carlo search > and an endgame solver is very effective. There is probably still much > strength to be gained (very little opponent modeling is done), but it's > already so strong I don't think it's getting much attention. I haven't kept up with the state of the art in scrabble but I know that MC techniques work well. I build a scrabble player years ago for my mother (who loves scrabble) and all it did was play the highest scoring move. To my surprise, she was able to beat it some significant percentage of the time and she is not a tournament or serious player. Computers have a real advantage having direct access to the entire dictionary, but still it requires more than that.I assume the best computer players are better than the best humans. - Don > Looks like there's about 700 elo between the top Arimaa bot and human. I > suppose for go it is quite a bit more? > > For single player games, there are definitely many types of puzzles that > computers struggle with. Sokoban is a puzzle I saw a while ago that is > still difficult for computers. I don't think I'd say it's harder than go, > though. > http://www.grappa.univ-lille3.fr/icga/phpBB3/viewtopic.php?f=2&t=35 > > > - Original Message - > From: "Darren Cook" <[EMAIL PROTECTED]> > To: > Sent: Monday, October 27, 2008 8:54 PM > Subject: Re: [computer-go] OT: Harder than go? > > > >>> Where "harder" means the gap between top programs and top human players > >>> is bigger, are there any games harder than go? Including games of > >>> imperfect information, multi-player games, single-player puzzle games. > >> > >> Poetry contests? > > > > I caught the smiley, but if you can define the rules (such that a > > mechanical referee can decide the winner, as in all games from go to > > poker to scrabble) then I guess the computer would be strong [1]. > > > > Thanks for the Arimaa and Havannah suggestions; I'd not heard of > > Havannah before. I see both have bets by humans that they'll not be > > beaten any time soon. > > > > David, is MCTS likely to be useful for Arimaa? > > > > Darren > > > > [1]: Though http://en.wikipedia.org/wiki/Scrabble#Computer_players is > > ambiguous about if computer scrabble players are stronger than human > > players or not. > > > > -- > > Darren Cook, Software Researcher/Developer > > http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic > >open source dictionary/semantic network) > > http://dcook.org/work/ (About me and my work) > > http://dcook.org/blogs.html (My blogs and articles) > > ___ > > 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/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
What do those number mean exactly? Are those winning percentages against your ref-bot with 1,000 playouts? I'm not getting the same results as Michael does. I see some improvement, but not nearly as much. I had to make a few changes however, as I was adding up the results in a different way than your ref-bot. So what I did was implement tracking the AMAF statistics exactly the same way as in your ref-bot. Next I ran a few hundred games, comparing the win/hit ratio of the newly implemented method with my old one to make sure I got the same result. When that checked out I made the modifications as described by Michael. It seems rather straightforward, but after 200 games I only get a win-rate of ~55% with 2,000 playouts instead of the 63% he has. That's a considerable difference. Possibly I introduced a little bug somewhere... Or I need a larger test-sample. I do agree with Michael that this idea is more logical and simpler. I had implemented a different way to check which side moved at which location first. I believe it's more efficient but it doesn't lend itself for Michael's method. However, your way of checking seems rather costly as it's a loop of 1/4 N^2 iterations, where N is the number of moves (which we know is 111 in the beginning). With Michael's method this is reduced to 1/2N iterations. My ref-bot on CGOS is still going. It seems to be always within a few ELO points of your Jref and Cref bots. So I'm going to stop it as I don't see much point in populating CGOS with identical bots. It has played over 500 games, which I think is enough empirical evidence that the implementation is 'good enough'. Mark On 28-okt-08, at 10:54, Don Dailey wrote: I have empirical evidence that mwRefbot level 4096 (the Michael Williams enhanced reference bot at 4096 playouts) is stronger than the reference bot at the same (and even higher levels.) Rank Name Elo+- games score oppo. draws 1 mwRefbot-004096 2684 23 22 1529 78% 21400% 2 refbot-0081922670 21 21 1532 73% 22740% 3 refbot-0040962645 21 21 1528 71% 22510% 4 refbot-0020482555 21 21 1530 63% 22370% 5 refbot-0010242431 23 23 1529 54% 21780% 6 refbot-0005122253 27 28 1531 47% 20660% 7 refbot-0002562000 34 35 1529 42% 19320% 8 refbot-0001281646 42 42 1529 45% 16550% 9 refbot-641290 40 40 1529 50% 13210% 10 refbot-32 970 40 40 1531 52% 10410% 11 refbot-16 621 33 32 1529 55% 7800% 12 refbot-08 370 25 25 1529 47% 6490% 13 refbot-04 250 23 22 1529 43% 5510% 14 refbot-02 145 22 22 1529 35% 5000% 15 refbot-01 5 22 23 1528 22% 4750% 16 refbot-00 0 22 23 1531 22% 4840% - 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] OT: Harder than go? - MCTS for Arimaa
David Fotland wrote: > I've thought about using mcts for Arimaa, and it might be better than > alpha-beta. Arimaa has a huge branching factor, and since the pieces move > slowly, human long-term planning works well against computers. Mcts prunes > better, so it should get deeper PVs. AMAF might help too, since in a long > plan it is often not critical what order the moves are in. > > Someone should give it a try. > >> David, is MCTS likely to be useful for Arimaa? >> >> Darren >> Jeff Bacher author of Clueless gave UCT w/light playouts a try a few years ago but without much success. If I'm remembering correctly it played fairly decent in the end game, but for most of the game was much to prone to advancing rabbits on the off chance that they could sneak through. I also gave UCT a bit of a try but never got it playing much better than a 1 ply static evaluation. If I can get my alpha-beta program up to the same level as yours I would like to go explore MCTS and other search methods some more. There have been a number of new programs in development this year but I'm not aware of any of the ones that have made it to the stage of actually playing games being anything other than alpha-beta. Janzert ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
My original chart of numbers was created before it occurred to me that maybe the check whether the move has been played before is not needed. It is of course possible that the check IS needed. I ran a new test after removing that check and the numbers don't look as good: At1 playouts per move, the modified version wins 47.8% of the time (±2.2%) after 500 games. At2 playouts per move, the modified version wins 52.2% of the time (±2.2%) after 500 games. At4 playouts per move, the modified version wins 56.3% of the time (±2.9%) after 300 games. At8 playouts per move, the modified version wins 60.3% of the time (±2.8%) after 300 games. At 16 playouts per move, the modified version wins 58.3% of the time (±2.8%) after 300 games. At 32 playouts per move, the modified version wins 57.3% of the time (±2.9%) after 300 games. At 64 playouts per move, the modified version wins 54.3% of the time (±2.9%) after 300 games. At 128 playouts per move, the modified version wins 51.3% of the time (±2.9%) after 300 games. At 256 playouts per move, the modified version wins 57.0% of the time (±2.9%) after 300 games. At 512 playouts per move, the modified version wins 52.7% of the time (±2.9%) after 300 games. At 1024 playouts per move, the modified version wins 46.0% of the time (±2.9%) after 300 games. At 2048 playouts per move, the modified version wins 54.3% of the time (±2.9%) after 300 games. At 4096 playouts per move, the modified version wins 57.7% of the time (±2.9%) after 300 games. Don, did you retain the check in your version that has the weighted AMAF? What ever you did, could you also add a version to the study that does the opposite? Mark Boon wrote: What do those number mean exactly? Are those winning percentages against your ref-bot with 1,000 playouts? I'm not getting the same results as Michael does. I see some improvement, but not nearly as much. I had to make a few changes however, as I was adding up the results in a different way than your ref-bot. So what I did was implement tracking the AMAF statistics exactly the same way as in your ref-bot. Next I ran a few hundred games, comparing the win/hit ratio of the newly implemented method with my old one to make sure I got the same result. When that checked out I made the modifications as described by Michael. It seems rather straightforward, but after 200 games I only get a win-rate of ~55% with 2,000 playouts instead of the 63% he has. That's a considerable difference. Possibly I introduced a little bug somewhere... Or I need a larger test-sample. I do agree with Michael that this idea is more logical and simpler. I had implemented a different way to check which side moved at which location first. I believe it's more efficient but it doesn't lend itself for Michael's method. However, your way of checking seems rather costly as it's a loop of 1/4 N^2 iterations, where N is the number of moves (which we know is 111 in the beginning). With Michael's method this is reduced to 1/2N iterations. My ref-bot on CGOS is still going. It seems to be always within a few ELO points of your Jref and Cref bots. So I'm going to stop it as I don't see much point in populating CGOS with identical bots. It has played over 500 games, which I think is enough empirical evidence that the implementation is 'good enough'. Mark On 28-okt-08, at 10:54, Don Dailey wrote: I have empirical evidence that mwRefbot level 4096 (the Michael Williams enhanced reference bot at 4096 playouts) is stronger than the reference bot at the same (and even higher levels.) Rank Name Elo+- games score oppo. draws 1 mwRefbot-004096 2684 23 22 1529 78% 21400% 2 refbot-0081922670 21 21 1532 73% 22740% 3 refbot-0040962645 21 21 1528 71% 22510% 4 refbot-0020482555 21 21 1530 63% 22370% 5 refbot-0010242431 23 23 1529 54% 21780% 6 refbot-0005122253 27 28 1531 47% 20660% 7 refbot-0002562000 34 35 1529 42% 19320% 8 refbot-0001281646 42 42 1529 45% 16550% 9 refbot-641290 40 40 1529 50% 13210% 10 refbot-32 970 40 40 1531 52% 10410% 11 refbot-16 621 33 32 1529 55% 7800% 12 refbot-08 370 25 25 1529 47% 6490% 13 refbot-04 250 23 22 1529 43% 5510% 14 refbot-02 145 22 22 1529 35% 5000% 15 refbot-01 5 22 23 1528 22% 4750% 16 refbot-00 0 22 23 1531 22% 4840% - 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] Michael Williams enhancement
On Tue, 2008-10-28 at 12:48 -0200, Mark Boon wrote: > What do those number mean exactly? Are those winning percentages > against your ref-bot with 1,000 playouts? No, it is a massive tournament where each player is scheduled in a manner similar to CGOS.The number of playouts is identified by the name of the program, i.e. refbot-08192 is 8192 playouts. So what I see in the table is that mwRefbot at 4096 playouts is stronger than refbot-08192. mwRefbot is the mark williams enhanced bot. refbot-0 has ZERO playouts - it plays a move randomly. refbot-1 has 1 playout and of course is almost but not quite random. I define 0 or random play to be ELO 0 - Don > > I'm not getting the same results as Michael does. I see some > improvement, but not nearly as much. > > I had to make a few changes however, as I was adding up the results > in a different way than your ref-bot. So what I did was implement > tracking the AMAF statistics exactly the same way as in your ref-bot. > Next I ran a few hundred games, comparing the win/hit ratio of the > newly implemented method with my old one to make sure I got the same > result. When that checked out I made the modifications as described > by Michael. It seems rather straightforward, but after 200 games I > only get a win-rate of ~55% with 2,000 playouts instead of the 63% he > has. That's a considerable difference. > > Possibly I introduced a little bug somewhere... Or I need a larger > test-sample. > > I do agree with Michael that this idea is more logical and simpler. I > had implemented a different way to check which side moved at which > location first. I believe it's more efficient but it doesn't lend > itself for Michael's method. However, your way of checking seems > rather costly as it's a loop of 1/4 N^2 iterations, where N is the > number of moves (which we know is 111 in the beginning). With > Michael's method this is reduced to 1/2N iterations. > > My ref-bot on CGOS is still going. It seems to be always within a few > ELO points of your Jref and Cref bots. So I'm going to stop it as I > don't see much point in populating CGOS with identical bots. It has > played over 500 games, which I think is enough empirical evidence > that the implementation is 'good enough'. > > Mark > > > On 28-okt-08, at 10:54, Don Dailey wrote: > > > I have empirical evidence that mwRefbot level 4096 (the Michael > > Williams > > enhanced reference bot at 4096 playouts) is stronger than the > > reference > > bot at the same (and even higher levels.) > > > > > > Rank Name Elo+- games score oppo. draws > >1 mwRefbot-004096 2684 23 22 1529 78% 21400% > >2 refbot-0081922670 21 21 1532 73% 22740% > >3 refbot-0040962645 21 21 1528 71% 22510% > >4 refbot-0020482555 21 21 1530 63% 22370% > >5 refbot-0010242431 23 23 1529 54% 21780% > >6 refbot-0005122253 27 28 1531 47% 20660% > >7 refbot-0002562000 34 35 1529 42% 19320% > >8 refbot-0001281646 42 42 1529 45% 16550% > >9 refbot-641290 40 40 1529 50% 13210% > > 10 refbot-32 970 40 40 1531 52% 10410% > > 11 refbot-16 621 33 32 1529 55% 7800% > > 12 refbot-08 370 25 25 1529 47% 6490% > > 13 refbot-04 250 23 22 1529 43% 5510% > > 14 refbot-02 145 22 22 1529 35% 5000% > > 15 refbot-01 5 22 23 1528 22% 4750% > > 16 refbot-00 0 22 23 1531 22% 4840% > > > > - Don > > > > > > ___ > > computer-go mailing list > > computer-go@computer-go.org > > http://www.computer-go.org/mailman/listinfo/computer-go/ > signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
Hehe, this reminds me of the title of a CNN program: 'Keeping them honest' ;-) OK, let me add that check back in to see if I get better results. Mark On 28-okt-08, at 13:18, Michael Williams wrote: My original chart of numbers was created before it occurred to me that maybe the check whether the move has been played before is not needed. It is of course possible that the check IS needed. I ran a new test after removing that check and the numbers don't look as good: ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
If you look at my original email, I did not mention removing that until after I showed and discussed the numbers. And even then, I said "... it is probably safe to remove...". Probably being the operative word indicating that I had not yet tested that. Mark Boon wrote: Hehe, this reminds me of the title of a CNN program: 'Keeping them honest' ;-) OK, let me add that check back in to see if I get better results. Mark On 28-okt-08, at 13:18, Michael Williams wrote: My original chart of numbers was created before it occurred to me that maybe the check whether the move has been played before is not needed. It is of course possible that the check IS needed. I ran a new test after removing that check and the numbers don't look as good: ___ 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] Michael Williams enhancement
You can add the check back in and be more efficient than Don's nested loop by
doing something like this (warning: untested code)...
for (int mv = 0; mv < NNN; mv++)
{
credit[mv] = true; // initial assumption is that credit is awarded
for any move
}
double weight = 1.0;
double weightDelta = 2.0 / (ctm - savctm + 1);
for (int i = savctm; i < ctm; i += 2)
{
int mv = mvs[i] & MASK;
if (credit[mv])
{
wins[mv] += weight * sc;
hits[mv] += weight;
credit[mv] = false; // do not award credit for this move again
}
weight -= weightDelta;
credit[mvs[i+1] & MASK] = false; // do not award credit for the
opponent's move
}
Mark Boon wrote:
Hehe, this reminds me of the title of a CNN program: 'Keeping them
honest' ;-)
OK, let me add that check back in to see if I get better results.
Mark
On 28-okt-08, at 13:18, Michael Williams wrote:
My original chart of numbers was created before it occurred to me that
maybe the check whether the move has been played before is not
needed. It is of course possible that the check IS needed. I ran a
new test after removing that check and the numbers don't look as good:
___
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] Michael Williams enhancement
On Tue, 2008-10-28 at 12:48 -0200, Mark Boon wrote: > What do those number mean exactly? Are those winning percentages > against your ref-bot with 1,000 playouts? > > I'm not getting the same results as Michael does. I see some > improvement, but not nearly as much. > > I had to make a few changes however, as I was adding up the results > in a different way than your ref-bot. So what I did was implement > tracking the AMAF statistics exactly the same way as in your ref-bot. > Next I ran a few hundred games, comparing the win/hit ratio of the > newly implemented method with my old one to make sure I got the same > result. When that checked out I made the modifications as described > by Michael. It seems rather straightforward, but after 200 games I > only get a win-rate of ~55% with 2,000 playouts instead of the 63% he > has. That's a considerable difference. > > Possibly I introduced a little bug somewhere... Or I need a larger > test-sample. > > I do agree with Michael that this idea is more logical and simpler. It's simpler for sure, more logical I don't agree. The simplest thing is just to say test every move and don't worry about counting ko moves multiple times or giving credit for moves the opponent plays first (in which case you don't really deserve credit for that move.) It's clearly not very logical and it plays weaker too. Like I say, I had to make a decision on this one way or the other so I went with what was the more standard approach since I believed it to be more logical, stronger playing, and more correct. However, with Michael what I was arguing against wasn't the update style, but his progressive bias against later moves - clearly good, but clearly a performance enhancement and a more complicated specification. If I accepted that, it would be difficult to refuse every other little tweak and enhancement that others will be sending me. For instance, this is not a new idea - Christoph Birk has used it in his bot, but he uses a more sophisticated decaying weight that is not linear. Why should I use the Williams function instead of the Birk function? Or some other function?Do you see why you have to draw a line in the sand somewhere? > I > had implemented a different way to check which side moved at which > location first. I believe it's more efficient but it doesn't lend > itself for Michael's method. However, your way of checking seems > rather costly as it's a loop of 1/4 N^2 iterations, where N is the > number of moves (which we know is 111 in the beginning). With > Michael's method this is reduced to 1/2N iterations. If you are worried about big-O characteristics, you don't have to implement this in a loop like I do. I did it that way to make it crystal clear what I was doing. A fast way is to use a perfect hash table to track duplicates. It's totally trivial. In this case a perfect hash table is a small array (large enough to encompass all the legal intersections) where the move IS the index (or you could say the move, which is an integer, IS the hash function.) If there are 81 points, zero out 81 elements in an array before you start gathering stats, then set that to 1 when you first encounter that move. The test is a single array lookup instead of an expensive loop. However, I didn't bother with all of that because I felt the code would be somewhat less clear.There are number of optimization like this that are in my own program that I didn't do here. This optimization is probably not worth very much. Compared to the cost of playing an actual game, this is probably not that expensive but I will test it for you. Maybe I will be surprised. The one optimization that I DID do, I probably should not have. The uniform random move selection loop is too complicated to understand with a quick glance at the code - but it's a huge performance gain over the most naive correct method and at the time it seemed too good to leave out. Also, I wanted the reference bot to not be too slow since I envision it being used to test other references against. - Don > > My ref-bot on CGOS is still going. It seems to be always within a few > ELO points of your Jref and Cref bots. So I'm going to stop it as I > don't see much point in populating CGOS with identical bots. It has > played over 500 games, which I think is enough empirical evidence > that the implementation is 'good enough'. > > Mark > > > On 28-okt-08, at 10:54, Don Dailey wrote: > > > I have empirical evidence that mwRefbot level 4096 (the Michael > > Williams > > enhanced reference bot at 4096 playouts) is stronger than the > > reference > > bot at the same (and even higher levels.) > > > > > > Rank Name Elo+- games score oppo. draws > >1 mwRefbot-004096 2684 23 22 1529 78% 21400% > >2 refbot-0081922670 21 21 1532 73% 22740% > >3 refbot-0040962645 21 21 1528 71% 225
Re: [computer-go] OT: Harder than go? - MCTS for Arimaa
MCTS seems to be not very useful for some games, but I think it needs a lot more research. I tried it will chess with really dismal results. Even the mighty Rybka team has a MC mode which is a curiosity, it plays much weaker than the standard program. I have this feeling that you ought to be able to at least approach the same level of strength but it would require a lot of domain specific enhancements appropriate to the particular game.In chess for instance, a 1 ply search with a weak evaluation function and very little effort gives you a better move that a million random simulations, but that is probably not true in GO. So one would have to determine what you can and cannot do well with the different approaches and try to meld them in some way that makes sense. - Don On Tue, 2008-10-28 at 11:13 -0400, Janzert wrote: > David Fotland wrote: > > I've thought about using mcts for Arimaa, and it might be better than > > alpha-beta. Arimaa has a huge branching factor, and since the pieces move > > slowly, human long-term planning works well against computers. Mcts prunes > > better, so it should get deeper PVs. AMAF might help too, since in a long > > plan it is often not critical what order the moves are in. > > > > Someone should give it a try. > > > >> David, is MCTS likely to be useful for Arimaa? > >> > >> Darren > >> > > Jeff Bacher author of Clueless gave UCT w/light playouts a try a few > years ago but without much success. If I'm remembering correctly it > played fairly decent in the end game, but for most of the game was much > to prone to advancing rabbits on the off chance that they could sneak > through. > > I also gave UCT a bit of a try but never got it playing much better than > a 1 ply static evaluation. If I can get my alpha-beta program up to the > same level as yours I would like to go explore MCTS and other search > methods some more. > > There have been a number of new programs in development this year but > I'm not aware of any of the ones that have made it to the stage of > actually playing games being anything other than alpha-beta. > > Janzert > > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
On Tue, 2008-10-28 at 11:18 -0400, Michael Williams wrote: > Don, did you retain the check in your version that has the weighted > AMAF? No, I eliminated the check so that I could give an apples to apples assessment of the idea exactly as Michael Williams suggested. > What ever you did, could you also add a version to the study that does > the opposite? I think the right way to do that is to first compute how many moves are actually going to be used, then use the formula directly. Right now, if you use the test and his formula you would get uneven weightings, gaps as it were.Probably no big deal. Another idea is to weight as a function of how many points are on the board. So the question is do you compensate in any way for the missing moves or do you simply have the check and ignore the gaps? If you actually want to use something in a real program you should test all reasonable ideas and just see what works. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
Don, Don't get me wrong, I understand very well where you're coming from. It's very handy to have a concise defintion of a minimalist playing program that can be used to check correctness. The main reason I thought Michael's idea was worth considering was that it was both simpler AND played better AND scaled better. But if in order to get a meaningful boost in strength you have to maintain some sort of check whether a move was played by one side before, then I agree it may be better to leave his improvement out of the reference specification. Mark On 28-okt-08, at 13:49, Don Dailey wrote: On Tue, 2008-10-28 at 12:48 -0200, Mark Boon wrote: What do those number mean exactly? Are those winning percentages against your ref-bot with 1,000 playouts? I'm not getting the same results as Michael does. I see some improvement, but not nearly as much. I had to make a few changes however, as I was adding up the results in a different way than your ref-bot. So what I did was implement tracking the AMAF statistics exactly the same way as in your ref-bot. Next I ran a few hundred games, comparing the win/hit ratio of the newly implemented method with my old one to make sure I got the same result. When that checked out I made the modifications as described by Michael. It seems rather straightforward, but after 200 games I only get a win-rate of ~55% with 2,000 playouts instead of the 63% he has. That's a considerable difference. Possibly I introduced a little bug somewhere... Or I need a larger test-sample. I do agree with Michael that this idea is more logical and simpler. It's simpler for sure, more logical I don't agree. The simplest thing is just to say test every move and don't worry about counting ko moves multiple times or giving credit for moves the opponent plays first (in which case you don't really deserve credit for that move.) It's clearly not very logical and it plays weaker too. Like I say, I had to make a decision on this one way or the other so I went with what was the more standard approach since I believed it to be more logical, stronger playing, and more correct. However, with Michael what I was arguing against wasn't the update style, but his progressive bias against later moves - clearly good, but clearly a performance enhancement and a more complicated specification. If I accepted that, it would be difficult to refuse every other little tweak and enhancement that others will be sending me. For instance, this is not a new idea - Christoph Birk has used it in his bot, but he uses a more sophisticated decaying weight that is not linear. Why should I use the Williams function instead of the Birk function? Or some other function?Do you see why you have to draw a line in the sand somewhere? I had implemented a different way to check which side moved at which location first. I believe it's more efficient but it doesn't lend itself for Michael's method. However, your way of checking seems rather costly as it's a loop of 1/4 N^2 iterations, where N is the number of moves (which we know is 111 in the beginning). With Michael's method this is reduced to 1/2N iterations. If you are worried about big-O characteristics, you don't have to implement this in a loop like I do. I did it that way to make it crystal clear what I was doing. A fast way is to use a perfect hash table to track duplicates. It's totally trivial. In this case a perfect hash table is a small array (large enough to encompass all the legal intersections) where the move IS the index (or you could say the move, which is an integer, IS the hash function.) If there are 81 points, zero out 81 elements in an array before you start gathering stats, then set that to 1 when you first encounter that move. The test is a single array lookup instead of an expensive loop. However, I didn't bother with all of that because I felt the code would be somewhat less clear.There are number of optimization like this that are in my own program that I didn't do here. This optimization is probably not worth very much. Compared to the cost of playing an actual game, this is probably not that expensive but I will test it for you. Maybe I will be surprised. The one optimization that I DID do, I probably should not have. The uniform random move selection loop is too complicated to understand with a quick glance at the code - but it's a huge performance gain over the most naive correct method and at the time it seemed too good to leave out. Also, I wanted the reference bot to not be too slow since I envision it being used to test other references against. - Don My ref-bot on CGOS is still going. It seems to be always within a few ELO points of your Jref and Cref bots. So I'm going to stop it as I don't see much point in populating CGOS with identical bots. It has played over 500 games, which I think is enough empirical evidence that the implementation is 'go
Re: [computer-go] Michael Williams enhancement
On Tue, 2008-10-28 at 11:40 -0400, Michael Williams wrote: > If you look at my original email, I did not mention removing that > until after I showed and discussed the numbers. And even then, I said > "... it is probably > safe to remove...". Probably being the operative word indicating that > I had not yet tested that. I used your pseudo code, which didn't have the check in it. In tests I had done in the past, it didn't really make much difference. I had to run a lot of game to conclude that having the test seemed to make it slightly stronger and I don't think I ran enough to make this very conclusive. In general, I stop testing when it becomes clear that something won't make a big enough difference to worry too much about - then I use some other criteria - my gut feeling, simplicity, aesthetics, etc. But that is probably not good to do. Imagine ignoring a dozen 10 ELO enhancements because you were not willing to get enough data to prove each was a tiny improvement. You may have thrown away 100 ELO over time. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
On Tue, 2008-10-28 at 14:08 -0200, Mark Boon wrote: > Don, > > Don't get me wrong, I understand very well where you're coming from. > It's very handy to have a concise defintion of a minimalist playing > program that can be used to check correctness. The main reason I > thought Michael's idea was worth considering was that it was both > simpler AND played better AND scaled better. But if in order to get > a > meaningful boost in strength you have to maintain some sort of check > whether a move was played by one side before, then I agree it may be > better to leave his improvement out of the reference specification. The important idea here of course is the decaying weights, not whether to do the "already played" check. It's clearly simpler not to do the check. And with decaying weights ignoring the check would have less impact anyway. So don't get me wrong either, I definitely like the idea and find it a useful enhancement. I think we will accumulate a number of useful enhancement to the simple reference bot and I want to track them on this web site (the web site that doesn't yet exist :-) - Don > > Mark signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
Yes, this is the hash table idea I mentioned, although most people don't
view this as a hash table - it is.
The enhanced version has actually improved it's result over the past
couple of hours:
Rank Name Elo+- games score oppo. draws
1 mwRefbot-004096 2691 22 21 1642 78% 21580%
2 refbot-0081922675 20 20 1642 73% 22770%
3 refbot-0040962650 20 20 1642 71% 22570%
4 refbot-0020482564 20 20 1642 63% 22420%
5 refbot-0010242440 22 22 1642 55% 21770%
6 refbot-0005122265 26 26 1642 48% 20670%
7 refbot-0002562006 33 34 1644 42% 19380%
8 refbot-0001281651 40 41 1643 45% 16570%
9 refbot-641293 39 39 1644 51% 13210%
10 refbot-32 975 38 38 1643 52% 10520%
11 refbot-16 630 32 31 1642 55% 7860%
12 refbot-08 375 24 24 1642 47% 6540%
13 refbot-04 256 22 22 1643 43% 5610%
14 refbot-02 148 21 21 1642 35% 5000%
15 refbot-01 6 22 22 1644 21% 4870%
16 refbot-00 0 21 22 1643 21% 4890%
- Don
On Tue, 2008-10-28 at 11:41 -0400, Michael Williams wrote:
> You can add the check back in and be more efficient than Don's nested loop by
> doing something like this (warning: untested code)...
>
>
>
> for (int mv = 0; mv < NNN; mv++)
> {
> credit[mv] = true; // initial assumption is that credit is
> awarded for any move
> }
> double weight = 1.0;
> double weightDelta = 2.0 / (ctm - savctm + 1);
> for (int i = savctm; i < ctm; i += 2)
> {
> int mv = mvs[i] & MASK;
>
> if (credit[mv])
> {
> wins[mv] += weight * sc;
> hits[mv] += weight;
> credit[mv] = false; // do not award credit for this move
> again
> }
> weight -= weightDelta;
>
> credit[mvs[i+1] & MASK] = false; // do not award credit for the
> opponent's move
> }
>
>
>
>
> Mark Boon wrote:
> > Hehe, this reminds me of the title of a CNN program: 'Keeping them
> > honest' ;-)
> >
> > OK, let me add that check back in to see if I get better results.
> >
> > Mark
> >
> > On 28-okt-08, at 13:18, Michael Williams wrote:
> >
> >> My original chart of numbers was created before it occurred to me that
> >> maybe the check whether the move has been played before is not
> >> needed. It is of course possible that the check IS needed. I ran a
> >> new test after removing that check and the numbers don't look as good:
> >>
> >
> >
> >
> >
> > ___
> > 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/
signature.asc
Description: This is a digitally signed message part
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
I ran a quick test of the check in question combined with the decaying playouts. The one WITH the check won 70% at 2000 playouts over a 200 game match. Don Dailey wrote: On Tue, 2008-10-28 at 14:08 -0200, Mark Boon wrote: Don, Don't get me wrong, I understand very well where you're coming from. It's very handy to have a concise defintion of a minimalist playing program that can be used to check correctness. The main reason I thought Michael's idea was worth considering was that it was both simpler AND played better AND scaled better. But if in order to get a meaningful boost in strength you have to maintain some sort of check whether a move was played by one side before, then I agree it may be better to leave his improvement out of the reference specification. The important idea here of course is the decaying weights, not whether to do the "already played" check. It's clearly simpler not to do the check. And with decaying weights ignoring the check would have less impact anyway. So don't get me wrong either, I definitely like the idea and find it a useful enhancement. I think we will accumulate a number of useful enhancement to the simple reference bot and I want to track them on this web site (the web site that doesn't yet exist :-) - Don Mark ___ 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] Michael Williams enhancement
I shouldn't have gone on memory. It was actually 65.9% over 183 games. Michael Williams wrote: I ran a quick test of the check in question combined with the decaying playouts. The one WITH the check won 70% at 2000 playouts over a 200 game match. Don Dailey wrote: On Tue, 2008-10-28 at 14:08 -0200, Mark Boon wrote: Don, Don't get me wrong, I understand very well where you're coming from. It's very handy to have a concise defintion of a minimalist playing program that can be used to check correctness. The main reason I thought Michael's idea was worth considering was that it was both simpler AND played better AND scaled better. But if in order to get a meaningful boost in strength you have to maintain some sort of check whether a move was played by one side before, then I agree it may be better to leave his improvement out of the reference specification. The important idea here of course is the decaying weights, not whether to do the "already played" check. It's clearly simpler not to do the check. And with decaying weights ignoring the check would have less impact anyway. So don't get me wrong either, I definitely like the idea and find it a useful enhancement. I think we will accumulate a number of useful enhancement to the simple reference bot and I want to track them on this web site (the web site that doesn't yet exist :-) - Don Mark ___ 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] Michael Williams enhancement
On Tue, 2008-10-28 at 12:22 -0400, Michael Williams wrote: > I ran a quick test of the check in question combined with the decaying > playouts. The one WITH the check won 70% at 2000 playouts over a 200 game > match. I just queried my results at 4096 playouts and get very different numbers.It has only played 257 games so far, but the stats are 56.4% - far from 70%. It could be that: 1. I have a buggy implementation. 2. You have a buggy implementation of the non-enhanced version. 3. Diminishing returns (you played 2000, I played 4096 4. Statistical noise. (you high, me low, etc.) It could be some combination of the above or something else. I'm going to try a specific test of 2000 playouts. - Don irb(main):004:0> irb(main):005:0* 145 / 257.0 => 0.56420233463035 irb(main):006:0> > > Don Dailey wrote: > > On Tue, 2008-10-28 at 14:08 -0200, Mark Boon wrote: > >> Don, > >> > >> Don't get me wrong, I understand very well where you're coming from. > >> It's very handy to have a concise defintion of a minimalist playing > >> program that can be used to check correctness. The main reason I > >> thought Michael's idea was worth considering was that it was both > >> simpler AND played better AND scaled better. But if in order to get > >> a > >> meaningful boost in strength you have to maintain some sort of check > >> whether a move was played by one side before, then I agree it may be > >> better to leave his improvement out of the reference specification. > > > > The important idea here of course is the decaying weights, not whether > > to do the "already played" check. It's clearly simpler not to do the > > check. And with decaying weights ignoring the check would have less > > impact anyway. So don't get me wrong either, I definitely like the > > idea and find it a useful enhancement. > > > > I think we will accumulate a number of useful enhancement to the simple > > reference bot and I want to track them on this web site (the web site > > that doesn't yet exist :-) > > > > - Don > > > > > > > > > >> Mark > >> > >> > >> > >> ___ > >> 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/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Michael Williams enhancement
As promised I tested this on the C reference bot. I get almost a 12%
speedup - 36.0 seconds versus 40.2
- Don
On Tue, 2008-10-28 at 11:41 -0400, Michael Williams wrote:
> You can add the check back in and be more efficient than Don's nested loop by
> doing something like this (warning: untested code)...
>
>
>
> for (int mv = 0; mv < NNN; mv++)
> {
> credit[mv] = true; // initial assumption is that credit is
> awarded for any move
> }
> double weight = 1.0;
> double weightDelta = 2.0 / (ctm - savctm + 1);
> for (int i = savctm; i < ctm; i += 2)
> {
> int mv = mvs[i] & MASK;
>
> if (credit[mv])
> {
> wins[mv] += weight * sc;
> hits[mv] += weight;
> credit[mv] = false; // do not award credit for this move
> again
> }
> weight -= weightDelta;
>
> credit[mvs[i+1] & MASK] = false; // do not award credit for the
> opponent's move
> }
>
>
>
>
> Mark Boon wrote:
> > Hehe, this reminds me of the title of a CNN program: 'Keeping them
> > honest' ;-)
> >
> > OK, let me add that check back in to see if I get better results.
> >
> > Mark
> >
> > On 28-okt-08, at 13:18, Michael Williams wrote:
> >
> >> My original chart of numbers was created before it occurred to me that
> >> maybe the check whether the move has been played before is not
> >> needed. It is of course possible that the check IS needed. I ran a
> >> new test after removing that check and the numbers don't look as good:
> >>
> >
> >
> >
> >
> > ___
> > 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/
signature.asc
Description: This is a digitally signed message part
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] The Enemy's Key Point Is My Own
"The enemy's key point is my own" is often invoked, for example, as a
reason to occupy the central point of a _nakade_ shape, or to play a
double sente point, or to make an extension that would also be an
extension for the opponent.
I would like now to talk about it in the context of the potential
modification of program behavior, or "style", via opponent modeling.
There's another oft-repeated maxim which states that "there are as many
styles of play as there are go-players." If true, this adage implies a
continuum along which each player may find himself or herself.
Or itself.
One measure of playing style is the degree to which the bulk of a given
player's selected behaviors display a concern with one's own position,
or a concern with the position of the enemy.
That is to say, or rather ask, of the moves in which a player most
often chooses to indulge, whether they exhibit what might be called
a "defensive" character, seeking to shore up or expand one's own
position, or do they instead more often exhibit a "combative"
character, seeking to destroy or diminish that of the other?
Of course all players indulge in both types of behavior, but we all
know that there are some players who prefer to build, and some who
prefer to destroy, when they are given a choice.
Now, for each potential behavior on the board -- even those acts in
which we would never choose to indulge -- suppose that we already have
a pair of numbers, in this case percentages, where one represents the
likelihood (or our belief about the probability) that such a point is
advantageous for us to play, and where another such number represents,
conversely, the likelihood (or our belief) that the same point (were we
to pass and it be selected by the foe) would be advantageous for the foe.
How we have arrived at these "probabilities" may be important,
certainly, but it's beyond the scope of this message. Let's
just say that we already have them.
Remembering that frequently-quoted proverb, namely: "The enemy's key
point is my own", we may wish to consider giving some weight to the
notion of playing on those points that we believe would be best for our
opponent to place a stone.
For example, suppose that it is our belief that a specific move has a
15% chance of being our best move, and say, a 35% chance of being best
for the foe.
If we give equal weight to these percentages, we may simply average
them, or "split the difference", arriving at a value of 25%, if we wish
to take advantage of the notion embodied in the proverb, as well the
notion of merely looking for plays that will be advantageous to our own
position. Note that this average is given by:
( 0.5 * 0.15 ) + ( 0.5 * 0.35 ) = 0.25
where the weights are equal, that is, fifty-fifty.
However, IRL ("in real life") each go player in the world is not only
likely to -- but in practice _does_ -- give a different weight, either
more or less, to each notion, as his character, or even his whim, dictates.
At the one extreme we may have a player who is defensive, pacifistic,
self-obsessed, overly-concerned about his own stones, to the point of
ignoring the other entirely. Such a player is oblivious to the foe's
plans and position, trying always to take one's own best point. Such
a player completely disregards the proverb: "The enemy's key point is
my own."
At the other extreme we have the player who is aggressive, combative,
entirely obsessed with the other, overly-concerned about the opponent's
stones, to the point of ignoring his own best interests entirely. Such
a player is oblivious to his own plans and postion, trying always to
take the foe's best point. This player has _pathologically_ taken to
heart the proverb: "_Only_ the enemy's key point is my own."
Both styles are pathological, and somewhere between these two extremes,
lies _every_ go-player, it seems.
Thus, a moderately-defensive player might be likely, instead of as in
the above example, to give more weight to the 15% chance (his own) and
less to the the 35% chance (the foe's).
I use the term "chance" loosely here, as we all know that go, being a
game of perfect information, does not depend on chance. [Whatever that is!]
Yet if a certain player were known to be, in general, say, about 63%
likely to be aggressive (and 37% defensive), we might then calculate
that his chance of selecting the above specific point is given by:
( 0.63 * 0.15 ) + ( 0.37 * 0.35 ) = 0.224
because such a player gives more weight (63%) to playing _our_ moves,
and less (37%) to playing his own.
In this particular example, there is not so much difference between our
original 50/50 estimate of the chance that this is a good move, and the
new, 63/37 estimate.
However, as the degree of aggressiveness of the player approaches one
or the other of the extremes, and also as our _a_priori_ beliefs vary
about the chances of a particular point being a good one for one or the
other of us, there are cases where the
[computer-go] enhanced test
It appears from testing 3 of us are doing, that the Mark Williams enhancement is good, and that testing to see if the move was played before is VERY GOOD when combined with the enhancement. The enhancement without the checking is perhaps 40 ELO stronger but with the testing it appears to be about 110 ELO stronger. Of course these numbers are rough estimates.I can give more precise numbers in a few hours. I'm round robin testing 3 versions against each other: 1. standard ref bot 2. mw enhanced - no first move test. 3. mw enhanced - with first move test. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] enhanced test
It's worth noting that the standard ref bot also has the first move test. Don Dailey wrote: It appears from testing 3 of us are doing, that the Mark Williams enhancement is good, and that testing to see if the move was played before is VERY GOOD when combined with the enhancement. The enhancement without the checking is perhaps 40 ELO stronger but with the testing it appears to be about 110 ELO stronger. Of course these numbers are rough estimates.I can give more precise numbers in a few hours. I'm round robin testing 3 versions against each other: 1. standard ref bot 2. mw enhanced - no first move test. 3. mw enhanced - with first move test. - 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] enhanced test
On Tue, 2008-10-28 at 15:07 -0400, Michael Williams wrote: > It's worth noting that the standard ref bot also has the first move test. Yes, so presumably even the weakest version is doing it the "best" way, i.e. doing the check. - Don > > > Don Dailey wrote: > > It appears from testing 3 of us are doing, that the Mark Williams > > enhancement is good, and that testing to see if the move was played > > before is VERY GOOD when combined with the enhancement. > > > > The enhancement without the checking is perhaps 40 ELO stronger but with > > the testing it appears to be about 110 ELO stronger. Of course these > > numbers are rough estimates.I can give more precise numbers in a few > > hours. I'm round robin testing 3 versions against each other: > > > >1. standard ref bot > > > >2. mw enhanced - no first move test. > > > >3. mw enhanced - with first move test. > > > > > > - 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/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Enemy's Key Point Is My Own
> From: Richard Brown <[EMAIL PROTECTED]> > > "The enemy's key point is my own" is often invoked, for example, as a > reason to occupy the central point of a _nakade_ shape, or to play a > double sente point, or to make an extension that would also be an > extension for the opponent. > Not only is the enemy's key point my own, but if I know _a_priori_ what > sorts of behavior in which my _specific_ enemy is likely to indulge, > perhaps I may be able to play, sometimes anyway, on the very points > where he or she (or it) is likely to play! > > The hypothesis outlined above, as of yet, has neither been confirmed > nor falsified by experimentation, but it kinda gives a whole new > meaning to the proverb, don't it? Sluggo has ( or had ) a particularly nasty form of "the enemy's key point is my own" - the program actually ran the GnuGo engine, so Sluggo knew precisely where GnuGo was most likely to play, and ( using a large cluster ) could give GnuGo a five stone handicap and win "convincingly and consistently", according to David Doshay, the author of Sluggo - google "sluggo gnugo evil twin" for more information. The downside of overfitting to a particular opponent is that little improvement versus other opponents was seen. I always wondered if it would be useful to exploit certain information which GnuGo knows how to calculate, but does not actually use in play - I suspect that life-and-death and semeai information which GnuGo knows how to discover may not actually be used, in some cases. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Enemy's Key Point Is My Own
On 28, Oct 2008, at 11:23 AM, Richard Brown wrote: ... if there is someone who can explain to me why I have the nagging suspicion that a differential equation is involved here, ... I cannot tell why you have this nagging suspicion, but I can say that if you wish to look into it deeper you can look up computer methods for dealing with dif Eqs on a discrete lattice. It may give you a better feeling one way or the other. Personally, in this case I do not see it, I only see continuous parameters on a discrete lattice. But I can add that SlugGo uses a modified version of the common Go Proverb "The Enemy's Key Point Is My Own" as part of its evaluation function. My experiments do show that this helps improve play in many cases, and leads to amazing blunders in others. It is worth pointing out that this proverb is too exact, and that it is far better to realize that if implemented in a program as it is stated you get the pathological behavior you mention. The truth is closer to: "Look near your opponent's best move to find things that are interesting" or possibly "when my good moves are near their good moves, that area may be more urgent that a big play elsewhere." Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Enemy's Key Point Is My Own
On Tue, 2008-10-28 at 12:28 -0700, terry mcintyre wrote: > The downside of overfitting to a particular opponent is that little > improvement versus other opponents was seen. I wonder what would happen if Sluggo used a second player (with a style much different from gnugo but still similar strength) as a source of plausible moves in addition to gnugo?Specifically a player that had different weaknesses and strengths. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] enhanced test
You should also test your 7/8 keep heuristic to see if it's reducing weight or avoiding the final moves that matters. Sent from my iPhone On Oct 28, 2008, at 3:03 PM, Don Dailey <[EMAIL PROTECTED]> wrote: It appears from testing 3 of us are doing, that the Mark Williams enhancement is good, and that testing to see if the move was played before is VERY GOOD when combined with the enhancement. The enhancement without the checking is perhaps 40 ELO stronger but with the testing it appears to be about 110 ELO stronger. Of course these numbers are rough estimates.I can give more precise numbers in a few hours. I'm round robin testing 3 versions against each other: 1. standard ref bot 2. mw enhanced - no first move test. 3. mw enhanced - with first move test. - 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] The Enemy's Key Point Is My Own
On 28, Oct 2008, at 12:28 PM, terry mcintyre wrote: Sluggo has ( or had ) a particularly nasty form of "the enemy's key point is my own" - the program actually ran the GnuGo engine, so Sluggo knew precisely where GnuGo was most likely to play, and ( using a large cluster ) could give GnuGo a five stone handicap and win "convincingly and consistently", according to David Doshay, the author of Sluggo - google "sluggo gnugo evil twin" for more information. While these things may be related, they are actually different code segments inside of SlugGo ... but the original post did mix the two somewhat as well. The Evil Twin Effect comes from correct modeling of the opponent's play in look ahead sequences. The effect in SlugGo is strong enough in games against GNU Go that with proper parameter settings and enough look ahead SlugGo could beat GNU Go with 9 stones. But as Terry says, that apparent strength not only did not make SlugGo stronger against other programs, it made it weaker. Too much weight was placed upon long look ahead sequences which were virtually certain to happen in a game against GNU Go, and had virtually no probability of happening in a game against anyone else. One nasty form of "The Enemy's Key Point Is My Own" was the "reverse monkey jump," where SlugGo would properly recognize that the opponent's best move against it was a monkey jump, and properly see that stopping that monkey jump was the best move, but it would then play the same exact point the opponent would have, thus playing way too far inside its own area. So, as I said in my earlier post, "near" is the right idea, not at the same point. There are other easy examples involving them extending towards our stones, where we should not take their extension as our move, but we should prevent their extension my moving into that area farther from our own stones than they would have approached. Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] enhanced test
On Tue, 2008-10-28 at 15:34 -0400, Jason House wrote: > You should also test your 7/8 keep heuristic to see if it's reducing > weight or avoiding the final moves that matters. I'm now also testing the reference bot that does NOT check for already played moves and it's at least 100 ELO weaker than even the reference bot. So it appears in all cases that checking for "already played" moves is quite important. Rank NameElo+- games score oppo. draws 1 mwNoDup-2000 2106 23 22 578 64% 20030% 2 mwRefbot-2000 2044 22 22 580 52% 20300% 3 refbot-20002000 22 22 581 43% 20500% 4 simple-20001858 41 44 199 25% 20500% These are 9x9, 7.5 komi round robin format. simple - reference bot without check for already played moves. mwNoDup - does the test for already played moves. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Enemy's Key Point Is My Own
David Doshay wrote: > One nasty form of "The Enemy's Key Point Is My Own" was the "reverse > monkey jump," where SlugGo would properly recognize that the opponent's > best move against it was a monkey jump, and properly see that stopping > that monkey jump was the best move, but it would then play the same > exact point the opponent would have, thus playing way too far inside its > own area. So, as I said in my earlier post, "near" is the right idea, > not at the same point. There are other easy examples involving them > extending towards our stones, where we should not take their extension > as our move, but we should prevent their extension my moving into that > area farther from our own stones than they would have approached. An extreme case is this life and death problem where playing the opponent's key point is the worst you can do locally. |O. |O. |.O.XOO |.XOX.O +-- /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The Enemy's Key Point Is My Own
SlugGo was never intended to just be the multi-headed global lookahead on top of GNU Go that it is today. The idea has always been to have multiple go engines inside. We just picked GNU Go for the first because when we started that was the only decent open source program, so we built the infrastructure around that engine. We are working on others, but it is happening slowly. The PhD topic is the combination of different expert systems and how to arbitrate between their suggestions, particularly when the experts use different representations for move quality/urgency. Cheers, David On 28, Oct 2008, at 12:34 PM, Don Dailey wrote: On Tue, 2008-10-28 at 12:28 -0700, terry mcintyre wrote: The downside of overfitting to a particular opponent is that little improvement versus other opponents was seen. I wonder what would happen if Sluggo used a second player (with a style much different from gnugo but still similar strength) as a source of plausible moves in addition to gnugo?Specifically a player that had different weaknesses and strengths. - 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] enhanced test
It makes me wonder if there are other classes of moves that can be segregated as AMAF-worthy and AMAF-unworthy. For instance, maybe capture moves played in the playout are only worth treating as first when the enemy did not add any stones to the chain that got captured. Of course, you can't do anything too complex that would significantly slow down the playouts. Don Dailey wrote: On Tue, 2008-10-28 at 15:07 -0400, Michael Williams wrote: It's worth noting that the standard ref bot also has the first move test. Yes, so presumably even the weakest version is doing it the "best" way, i.e. doing the check. - Don Don Dailey wrote: It appears from testing 3 of us are doing, that the Mark Williams enhancement is good, and that testing to see if the move was played before is VERY GOOD when combined with the enhancement. The enhancement without the checking is perhaps 40 ELO stronger but with the testing it appears to be about 110 ELO stronger. Of course these numbers are rough estimates.I can give more precise numbers in a few hours. I'm round robin testing 3 versions against each other: 1. standard ref bot 2. mw enhanced - no first move test. 3. mw enhanced - with first move test. - 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/ ___ 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] enhanced test
On Tue, 2008-10-28 at 15:34 -0400, Jason House wrote: > You should also test your 7/8 keep heuristic to see if it's reducing > weight or avoiding the final moves that matters. Yes, there is some overlap. The 7/8 rule avoids those cleanup moves at the end that are probably useless for choosing moves near the opening position. So my 7/8 is a dumbed down version of Michael Williams and Christoph Birk method. It could be that most of the benefit is avoiding moves near the end. I'm sure that the formula for decaying weight could be tweaked too but I would bet that 95% of the benefit can be had with something simple. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] enhanced test
On Tue, 2008-10-28 at 16:37 -0400, Michael Williams wrote: > It makes me wonder if there are other classes of moves that can be segregated > as AMAF-worthy and AMAF-unworthy. > > For instance, maybe capture moves played in the playout are only worth > treating > as first when the enemy did not add any stones to the chain that got captured. > Of course, you can't do anything too complex that would significantly slow > down the playouts. It's pretty tricky doing anything very clever without slowing things down a lot. But I am highly interested because I want to build a stronger Ogo type of program for handheld devices. I could probably improve Ogo already based on this idea of decaying weights. Ogo is the same as anchorMan but I don't like the tricks I use to get to 1500 ELO - they are pretty ugly hacks in my opinion. I could manage 5000 playouts without it taking too long on 9x9 but that is really an upper limit. One thing I once tried was to take statistics on each 3x3 pattern on the board instead of each move. So a move to c3 when not surrounded by anything is different that C3 when there is something around it. I didn't get any improvement from this - it was just slow and weak. The patterns really kill how many samples you can get from each playout and of course it's a major slowdown to an optimized program. So this is not just academic for me. I would like to find some more simple things (emphasis on simple) to improve basic bots. Of course tree search is not something I want to get into for a handheld device although it's possible. You clearly don't want a memory hog on a handheld device and you basically need fast response time to be practical. Of course there is a limit to how far you can go without tree search and fancy heuristics, but I think it might be possible to push this pretty far with some cleverness. I wonder if 1700 is out of the question? So I think it's possible to push the AMAF-worthy idea a little farther. If you look at actual games, you will see that one of the most common problems is self-atari to create an atari of it's own. The Ogo solution was artificial, I just detected that and gave it a little penalty. But I would like to find something more in the spirit of what we are doing now - not so domain specific. I'm also wondering what we could do by taking statistics on the opponents moves. I can't think of anything immediately obvious. - Don > > Don Dailey wrote: > > On Tue, 2008-10-28 at 15:07 -0400, Michael Williams wrote: > >> It's worth noting that the standard ref bot also has the first move test. > > > > Yes, so presumably even the weakest version is doing it the "best" way, > > i.e. doing the check. > > > > - Don > > > > > > > >> > >> Don Dailey wrote: > >>> It appears from testing 3 of us are doing, that the Mark Williams > >>> enhancement is good, and that testing to see if the move was played > >>> before is VERY GOOD when combined with the enhancement. > >>> > >>> The enhancement without the checking is perhaps 40 ELO stronger but with > >>> the testing it appears to be about 110 ELO stronger. Of course these > >>> numbers are rough estimates.I can give more precise numbers in a few > >>> hours. I'm round robin testing 3 versions against each other: > >>> > >>>1. standard ref bot > >>> > >>>2. mw enhanced - no first move test. > >>> > >>>3. mw enhanced - with first move test. > >>> > >>> > >>> - 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/ > >> > >> > >> > >> ___ > >> 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/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] enhanced test
This testing would be ideal for a boinc-style network of cooperative computers. It isn't time-critical, and does not require a lot of information exchange; each computer would run a series of multi-way tournaments, and the results would be collected. I'd be happy to volunteer part of my desktop computer for this purpose, and this study might gather as much support as the scalability studies a few months back. I like the way various tweaks are being compared, to determine their cost versus value. The keys to make this work are: low maintenance - a bit of setup and then forget about it - and some form of feedback to encourage participation. Terry McIntyre <[EMAIL PROTECTED]> -- Libertarians Do It With Consent! - Original Message > From: Don Dailey <[EMAIL PROTECTED]> > To: Jason House <[EMAIL PROTECTED]> > Cc: computer-go > Sent: Tuesday, October 28, 2008 12:51:53 PM > Subject: Re: [computer-go] enhanced test > > On Tue, 2008-10-28 at 15:34 -0400, Jason House wrote: > > You should also test your 7/8 keep heuristic to see if it's reducing > > weight or avoiding the final moves that matters. > > I'm now also testing the reference bot that does NOT check for already > played moves and it's at least 100 ELO weaker than even the reference > bot. > > So it appears in all cases that checking for "already played" moves is > quite important. > > Rank NameElo+- games score oppo. draws >1 mwNoDup-2000 2106 23 22 578 64% 20030% >2 mwRefbot-2000 2044 22 22 580 52% 20300% >3 refbot-20002000 22 22 581 43% 20500% >4 simple-20001858 41 44 199 25% 20500% > > > These are 9x9, 7.5 komi round robin format. > > simple - reference bot without check for already played moves. > mwNoDup - does the test for already played moves. > > > > > > > - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] enhanced test
>It's pretty tricky doing anything very clever without slowing things >down a lot. But I am highly interested because I want to build a >stronger Ogo type of program for handheld devices. Here's a suggestion: some mobile devices have volume-bound communication tariffs (internet or text messaging), and Go protocols are low-volume. So you could run a strong engine on your home machine, and add a mobile front-end for it. If your tariff is limited to small numbers of free/inclusive text messages, you might want to pre-compute several possible moves on the server and send tree fragments (rather than individual moves) to the mobile, for local execution/selection. Of course, even if you can stay within the cheap communications window, you might want to check which of communication and computation is going to run down the battery sooner.. Claus Ps. The suggestion is free. But if any of the commercial authors likes the idea enough to add it to their program, perhaps they could provide me with access to a free copy of their software in return?-) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Another enhancement to AMAF
The idea this time is to make use of your opponent's moves (as the proverb says). I tried a few different weights for the opponent move and 0.1 was the best of
the ones I tried. The win rates for the version with opponent moves versus the version without opponent moves are as follows (both versions use the weighted
AMAF recently discussed):
At 8 playouts, modified version wins 66.8% after 500 games.
At 64 playouts, modified version wins 56.6% after 500 games.
The advantage continues to decrease with more playouts. So it seems to perform better for a small number of playouts but doesn't scale well. I think this is
ok for a tree search program because you only run a few simulations before the node gets expanded. But I have not tried it in a tree search program yet.
Here is the code, so there is no ambiguity.
for (int mv = 0; mv < NNN; mv++)
{
credit[mv] = true; // initial assumption is that credit is awarded
for any move
}
double weight = 1.0;
double weightDelta = 2.0 / (ctm - savctm + 1);
for (int i = savctm; i < ctm; i += 2)
{
int mv = mvs[i] & MASK;
if (credit[mv])
{
wins[mv] += weight * sc;
hits[mv] += weight;
credit[mv] = false; // do not award credit for this move again
}
int opponentMove = mvs[i + 1] & MASK;
if (credit[opponentMove])
{
double opponentWeight = 0.1 * weight;
wins[opponentMove] -= opponentWeight * sc;
hits[opponentMove] += opponentWeight;
credit[opponentMove] = false; // do not award credit for this
move again
}
weight -= weightDelta;
}
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Another enhancement to AMAF
Some interesting ideas Michael, keep them coming.
With regards to the code-snippet you posted, this kind of
'mark-to-prevent-double-work' type of construction is very common in
computer-Go. Looping over the complete array to set the initial value
is very expensive and totally avoidable.
The same functionality could be achieved by the following:
marker++; // This is an int initialised to zero somewhere in
the beginning of your program.
double weight = 1.0;
double weightDelta = 2.0 / (ctm - savctm + 1);
for (int i = savctm; i < ctm; i += 2)
{
int mv = mvs[i] & MASK;
if (credit[mv]!=marker) // Note that credit[] is now an
array of int instead of boolean
{
wins[mv] += weight * sc;
hits[mv] += weight;
credit[mv] = marker; // do not award credit for this move
again
}
This is slightly simplified, just so you get the idea. To make it 100%
safe you need to check if marker==0 after the increment and clear the
credit array. This is so common I use a little helper class that wraps
this fucntionality for me, called BoardMarker. The code would look as
follows:
boardMarker.getNewMarker(); // BoardMarker is allocated
somewhere at the beginning of the program: BoardMarker boardMarker =
new BoardMarker();
double weight = 1.0;
double weightDelta = 2.0 / (ctm - savctm + 1);
for (int i = savctm; i < ctm; i += 2)
{
int mv = mvs[i] & MASK;
if (boardMarker.notSet(mv))
{
wins[mv] += weight * sc;
hits[mv] += weight;
boardMarker.set(mv); // do not award credit for this move
again
}
Disclaimer, my code is not like this (yet) so I didn't try this for
real. But it should work.
On Tue, Oct 28, 2008 at 8:43 PM, Michael Williams
<[EMAIL PROTECTED]> wrote:
>for (int mv = 0; mv < NNN; mv++)
>{
>credit[mv] = true; // initial assumption is that credit is
> awarded for any move
>}
>double weight = 1.0;
>double weightDelta = 2.0 / (ctm - savctm + 1);
>for (int i = savctm; i < ctm; i += 2)
>{
>int mv = mvs[i] & MASK;
>
>if (credit[mv])
>{
>wins[mv] += weight * sc;
>hits[mv] += weight;
>credit[mv] = false; // do not award credit for this move
> again
>}
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Another enhancement to AMAF
The marker idea I call aging. I call the variable age because it seems
to be more descriptive to me. Each playout has a different age
associated with it. The idea is used in persistent hash tables in
computer chess and I'm sure in other games too.
However, I seriously doubt this particular enhancement is even worth
doing in this context. It may even be difficult to measure the speedup
it will give you. I would be surprised if you get 1/2 percent.
I don't initialize the array in a loop either, I use memset in C. If I
did this is java I would use whatever java method is the equivalent
assuming it is optimized.
If you want to save on initialization (which is pretty fast on modern
processors anyway) you can make this a bit array instead of an int
array. Then it would initialize about 32 times faster but you would
probably spend a little more time referencing it.
If you were to profile the code, I'll bet this would be one of the very
last sections of code you would bother optimizing. Still, if you are a
speed freak you would probably at some point get around to doing it just
because you can!
- Don
On Tue, 2008-10-28 at 21:24 -0200, Mark Boon wrote:
> Some interesting ideas Michael, keep them coming.
>
> With regards to the code-snippet you posted, this kind of
> 'mark-to-prevent-double-work' type of construction is very common in
> computer-Go. Looping over the complete array to set the initial value
> is very expensive and totally avoidable.
>
> The same functionality could be achieved by the following:
>
> marker++; // This is an int initialised to zero somewhere in
> the beginning of your program.
>
> double weight = 1.0;
> double weightDelta = 2.0 / (ctm - savctm + 1);
> for (int i = savctm; i < ctm; i += 2)
> {
> int mv = mvs[i] & MASK;
>
> if (credit[mv]!=marker) // Note that credit[] is now an
> array of int instead of boolean
> {
> wins[mv] += weight * sc;
> hits[mv] += weight;
> credit[mv] = marker; // do not award credit for this move
> again
> }
>
> This is slightly simplified, just so you get the idea. To make it 100%
> safe you need to check if marker==0 after the increment and clear the
> credit array. This is so common I use a little helper class that wraps
> this fucntionality for me, called BoardMarker. The code would look as
> follows:
>
>boardMarker.getNewMarker(); // BoardMarker is allocated
> somewhere at the beginning of the program: BoardMarker boardMarker =
> new BoardMarker();
>
> double weight = 1.0;
> double weightDelta = 2.0 / (ctm - savctm + 1);
> for (int i = savctm; i < ctm; i += 2)
> {
> int mv = mvs[i] & MASK;
>
> if (boardMarker.notSet(mv))
> {
> wins[mv] += weight * sc;
> hits[mv] += weight;
> boardMarker.set(mv); // do not award credit for this move
> again
> }
>
> Disclaimer, my code is not like this (yet) so I didn't try this for
> real. But it should work.
>
> On Tue, Oct 28, 2008 at 8:43 PM, Michael Williams
> <[EMAIL PROTECTED]> wrote:
> >for (int mv = 0; mv < NNN; mv++)
> >{
> >credit[mv] = true; // initial assumption is that credit is
> > awarded for any move
> >}
> >double weight = 1.0;
> >double weightDelta = 2.0 / (ctm - savctm + 1);
> >for (int i = savctm; i < ctm; i += 2)
> >{
> >int mv = mvs[i] & MASK;
> >
> >if (credit[mv])
> >{
> >wins[mv] += weight * sc;
> >hits[mv] += weight;
> >credit[mv] = false; // do not award credit for this move
> > again
> >}
> >
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
signature.asc
Description: This is a digitally signed message part
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The 2nd Comuputer Go UEC Cup
Seems Ito-sensen is very busy... The committee prepares a very limited number of volunteer operators. See "4-3 Volunteer Operators" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html for detail. Hideki David Fotland: <[EMAIL PROTECTED]>: >Do we have to show up in person, or can our programs be operated for us? > >David Fotland > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:computer-go- >> [EMAIL PROTECTED] On Behalf Of "TAKESHI ITO" >> Sent: Monday, October 27, 2008 7:22 PM >> To: computer-go@computer-go.org >> Subject: [computer-go] The 2nd Comuputer Go UEC Cup >> >> >> >> * >> CALL FOR PARTICIPATION >> >> The 2nd Computer Go UEC Cup >>The University of Electro-Communication, >>Tokyo, Japan, 13-14 December 2008 >>http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html >> * >> >> #Important Information >>Championship: December 13-14, 2008 >>Entry's Deadline: November 28, 2008 >> >> #Schedule >>December 13 >> Preliminary Match >>December 14 >> Final Tournament >> Exhibition Match >> Explanation by professional Igo player >> >> #Guest Comentator >>Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade) >> >> #Event >>Exhibition match: Ms.Kaori Aoba(4th-grade) VS Championship Program >> (Handicap Game) >> >> #Entry >>Cost:free >>Entry:accepting now >> http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html >> >> #Venue >>The University of Electro-communications >>: Building W-9 3F AV hall(campus map:40) >> 1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan. >> >> #Past >>The 1st Comuputer Go UEC Cup >> http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html >> >> #Host Organizer >>Cognitive Science and Entertainment (E&C) Research Station, >>The University of Electro-communications >> >> #Support >>Computer Go Forum >> >> #Contact (Tournament committee) >>[EMAIL PROTECTED] >> >> >> - >>Takeshi Ito >> The University of Electro-Communications >> [EMAIL PROTECTED] >> ___ >> 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/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The 2nd Comuputer Go UEC Cup
Seems Ito-sensei is very busy...
Remote computing is allowed. See "1-4: Using a Remote Host via the
Internet" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html
("Requirements for participation" in the side menu) for detail.
Hideki
David Doshay: <[EMAIL PROTECTED]>:
>Will remote computing be allowed, or do we need to have our hardware
>on site?
>
>Cheers,
>David
>
>
>
>On 27, Oct 2008, at 7:21 PM, TAKESHI ITO wrote:
>
>>
>>
>> *
>> CALL FOR PARTICIPATION
>>
>> The 2nd Computer Go UEC Cup
>> The University of Electro-Communication,
>> Tokyo, Japan, 13-14 December 2008
>> http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
>> *
>>
>> #Important Information
>> Championship: December 13-14, 2008
>> Entry's Deadline: November 28, 2008
>>
>> #Schedule
>> December 13
>> Preliminary Match
>> December 14
>> Final Tournament
>> Exhibition Match
>> Explanation by professional Igo player
>>
>> #Guest Comentator
>> Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
>>
>> #Event
>> Exhibition match: Ms.Kaori Aoba(4th-grade) VS Championship
>> Program (Handicap Game)
>>
>> #Entry
>> Cost:free
>> Entry:accepting now
>> http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
>>
>> #Venue
>> The University of Electro-communications
>> : Building W-9 3F AV hall(campus map:40)
>>1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan.
>>
>> #Past
>> The 1st Comuputer Go UEC Cup
>> http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html
>>
>> #Host Organizer
>> Cognitive Science and Entertainment (E&C) Research Station,
>> The University of Electro-communications
>>
>> #Support
>> Computer Go Forum
>>
>> #Contact (Tournament committee)
>> [EMAIL PROTECTED]
>>
>>
>> -
>> Takeshi Ito
>> The University of Electro-Communications
>> [EMAIL PROTECTED]
>> ___
>> 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/
--
[EMAIL PROTECTED] (Kato)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] The 2nd Comuputer Go UEC Cup
The protocol used is described as a "modified NNGS" protocol. The paragraph on
remote computing seems to suggest that no direct connection between the
Internet and the tournament is permitted; that an operator must manually
transfer moves from the remote computer to a GUI which is connected to the
local network. You'll want to tune your computer to leave a margin for that
manual transfer of information.
If I understand the site correctly, remote computing is permitted when the
computer is so huge that it cannot be brought to the venue.
Excerpt follows:
Another way to join the UEC Cup without bringing in a computer
is to use the Internet connection for game information exchange.
This is used when the computer of a competitor is so huge that
he/she cannot bring it to the venue. Because of security purpose,
we do not allow to play a game on the Internet.
The Internet connection must only be used for
communicating between a (possibly delegated) operator
in the conference room and a remote computer.
The operator then must use some GUI program
to play a match. See 2-2 for using GUI program. Anyone who want to use a remote
host must
submit a written format to the UEC Cup committee
at registration, and receive a permission for remote play.
2: Playing a Match
2-1 Playing through Network
Games are played over a TCP/IP network.
A game managing server will be set up to manage the game.
A programs should be able to play games over the network.
For the protocols, see Protocols.
2-2 Playing by hand
If games over the network are impossible for a program,
the competitor can manually input moves through the GUI program
the UEC Cup office prepares.
In this case, the following conditions will be applied.
The operator must input a move designated by the program.
If he/she input different moves, the competitor loses the game immediately.
The time to input moves is also clocked.
Terry McIntyre <[EMAIL PROTECTED]>
-- Libertarians Do It With Consent!
- Original Message
> From: Hideki Kato <[EMAIL PROTECTED]>
> To: computer-go
> Cc: TAKESHI ITO <[EMAIL PROTECTED]>
> Sent: Tuesday, October 28, 2008 8:00:06 PM
> Subject: Re: [computer-go] The 2nd Comuputer Go UEC Cup
>
> Seems Ito-sensei is very busy...
>
> Remote computing is allowed. See "1-4: Using a Remote Host via the
> Internet" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html
> ("Requirements for participation" in the side menu) for detail.
>
> Hideki
>
> David Doshay: <[EMAIL PROTECTED]>:
> >Will remote computing be allowed, or do we need to have our hardware
> >on site?
> >
> >Cheers,
> >David
> >
> >
> >
> >On 27, Oct 2008, at 7:21 PM, TAKESHI ITO wrote:
> >
> >>
> >>
> >> *
> >> CALL FOR PARTICIPATION
> >>
> >> The 2nd Computer Go UEC Cup
> >> The University of Electro-Communication,
> >> Tokyo, Japan, 13-14 December 2008
> >> http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
> >> *
> >>
> >> #Important Information
> >> Championship: December 13-14, 2008
> >> Entry's Deadline: November 28, 2008
> >>
> >> #Schedule
> >> December 13
> >> Preliminary Match
> >> December 14
> >> Final Tournament
> >> Exhibition Match
> >> Explanation by professional Igo player
> >>
> >> #Guest Comentator
> >> Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
> >>
> >> #Event
> >> Exhibition match: Ms.Kaori Aoba(4th-grade) VS Championship
> >> Program (Handicap Game)
> >>
> >> #Entry
> >> Cost:free
> >> Entry:accepting now
> >>http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
> >>
> >> #Venue
> >> The University of Electro-communications
> >> : Building W-9 3F AV hall(campus map:40)
> >>1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan.
> >>
> >> #Past
> >> The 1st Comuputer Go UEC Cup
> >> http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html
> >>
> >> #Host Organizer
> >> Cognitive Science and Entertainment (E&C) Research Station,
> >> The University of Electro-communications
> >>
> >> #Support
> >> Computer Go Forum
> >>
> >> #Contact (Tournament committee)
> >> [EMAIL PROTECTED]
> >>
> >>
> >> -
> >> Takeshi Ito
> >> The University of Electro-Communications
> >> [EMAIL PROTECTED]
> >> ___
> >> 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/
> --
> [EMAIL PROTECTED] (Kato)
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
_
Re: [computer-go] The 2nd Comuputer Go UEC Cup
This is wonderful news for SlugGo, but unfortunately my wife just
booked a
vacation for us at the same time. I will have to wait until next time
to be
able to attend.
I will plan to hold this time open next year and hope that you will be
holding
the tournament again at that time.
Thank you,
David
On 28, Oct 2008, at 8:00 PM, Hideki Kato wrote:
Seems Ito-sensei is very busy...
Remote computing is allowed. See "1-4: Using a Remote Host via the
Internet" at http://jsb.cs.uec.ac.jp/~igo/2008/eng/sankayouken.html
("Requirements for participation" in the side menu) for detail.
Hideki
David Doshay: <[EMAIL PROTECTED]>:
Will remote computing be allowed, or do we need to have our hardware
on site?
Cheers,
David
On 27, Oct 2008, at 7:21 PM, TAKESHI ITO wrote:
*
CALL FOR PARTICIPATION
The 2nd Computer Go UEC Cup
The University of Electro-Communication,
Tokyo, Japan, 13-14 December 2008
http://jsb.cs.uec.ac.jp/~igo/2008/eng/index.html
*
#Important Information
Championship: December 13-14, 2008
Entry's Deadline: November 28, 2008
#Schedule
December 13
Preliminary Match
December 14
Final Tournament
Exhibition Match
Explanation by professional Igo player
#Guest Comentator
Mr.Cheng Ming Huang(9th-grade), Ms.Kaori Aoba(4th-grade)
#Event
Exhibition match: Ms.Kaori Aoba(4th-grade) VS Championship
Program (Handicap Game)
#Entry
Cost:free
Entry:accepting now
http://jsb.cs.uec.ac.jp/~igo/2008/eng/mailform.html
#Venue
The University of Electro-communications
: Building W-9 3F AV hall(campus map:40)
1-5-1 Chofugaoka, Chofu-shi, Tokyo 182-8585 Japan.
#Past
The 1st Comuputer Go UEC Cup
http://jsb.cs.uec.ac.jp/~igo/2007/eng/index.html
#Host Organizer
Cognitive Science and Entertainment (E&C) Research Station,
The University of Electro-communications
#Support
Computer Go Forum
#Contact (Tournament committee)
[EMAIL PROTECTED]
-
Takeshi Ito
The University of Electro-Communications
[EMAIL PROTECTED]
___
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/
--
[EMAIL PROTECTED] (Kato)
___
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 enhancement to AMAF
On 29-okt-08, at 00:13, Don Dailey wrote: The marker idea I call aging. I call the variable age because it seems to be more descriptive to me. Each playout has a different age associated with it. The idea is used in persistent hash tables in computer chess and I'm sure in other games too. Yes, it could be seen as a form of aging. I use it for a whole lot of different things however, including things like not double-counting liberties, or making sure I process points only once in an area of unknown size beforehand. However, I seriously doubt this particular enhancement is even worth doing in this context. It may even be difficult to measure the speedup it will give you. I would be surprised if you get 1/2 percent. I don't initialize the array in a loop either, I use memset in C. If I did this is java I would use whatever java method is the equivalent assuming it is optimized. If you want to save on initialization (which is pretty fast on modern processors anyway) you can make this a bit array instead of an int array. Then it would initialize about 32 times faster but you would probably spend a little more time referencing it. If you were to profile the code, I'll bet this would be one of the very last sections of code you would bother optimizing. Still, if you are a speed freak you would probably at some point get around to doing it just because you can! This could very well be true. But old habits die hard! ;-) If I can save initialization of an array the size of a board within a loop I always do. And since I have the little class ready to use for cases like this it becomes a kind of reflex. It doesn't cost anything and using the class actually makes me less prone to making errors. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
