[computer-go] ELO Ratings of move pattern
Lars wrote: Anyone of you have similar or other experiences with the algorithm? I use at runtime the same Bradley-Terry formulas Remí introduces in his paper. That is a huge advance compared to naif urgency scores because it gives a measure of how hard it was to win for a move candidate. But I use a much simpler offline learning algorithm: Compute the naif score just as standard: sc[0] = (times played)/(times played + times postponed) Use this as an a priori value of the score. Then, iterating through all the games many times, create a compensation weight CW rewarding scores winning positions with high total of concurrent scores and diminishing those won too easily. Since the efficiency of the offline part of the program is not an issue, I make these in small steps iterating many times until they do almost nothing. Each time, I compare observed versus expected number of right guesses to see if it improves or not. sc[i] = CW*sc[i - 1] // * is elem by elem mul of a vector I guess it gets to more or less the same. Sure Remí's solution is more efficient and elegant. 2 more issues I am concerned about patterns: MIAI URGENCY: When two (or maybe more) moves are extremely urgent, but it is not important which of the two because they are equivalent. In this case the high urgency is masked by the fact that it is divided between two moves. IMPLICITLY CHECKED URGENCY: When an urgent pattern was already on the board and was not played its score is overestimated. Imagine threatening a bamboo joint, preserving the connection may be a huge point when it saves a big group without eyespace. But it may also be worth nothing when both groups are dead. When it first appears, there is a high probability that it is big and, therefore, its urgency should be high. But, if it wasn't played, then it is probably not big. The next times it has to be considered much less urgent than the first time. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Redirecting i/o in the Windows version of Mogo (Was in Re: Update of MoGo binary ..)
Edward de Grijs wrote: Can someone help me with this problem, for which I cannot find a solution: I am trying to run MoGo in an automatic way, using the cygwin toolkit. I guess you are trying to do this in Windows and using the Windows binary. If this is the case, you don't need any library. I did it and it works. Now, Linux supporters will enjoy this ;-), even as a Windows programmer I must admit that redirecting console i/o is one of the weirdest Windows features. The official Win32 reference example explaining how to do this has 245 lines of code!! (although many are remarks) If you have the Win32 reference in .hlp format search an article titled Creating a Child Process with Redirected Input and Output. If you don't, it must be public at MSDN. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: The global search myth
Dave Dyer wrote: In cases where the good moves are the obvious ones, you've found them anyway. Ok. Here I agree. In other cases, you prune them away. You are not really pruning, just postponing. Of course you may overlook moves of genius, who doesn't? But if your probabilities are correct you may be emulating what a human does. You DO get wrong answers much faster this way though. Why? I don't see why. I see this order as the most human like way of searching. As any incomplete search, it can blunder, but why more than any other incomplete search? Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] ELO Ratings of move pattern
Thanks for the file! This should be very helpful when I try to reproduce results. It looks like you are not taking advantage of symmetries. For instance, 88|0|17.033168 88|1|12.263955 and 164|0|17.388714 164|1|25.862695 Are identical except for swapping the roles of white and black (88 == 1120 in base 4, 164 == 2210 in base 4), and therefore they should have the same scores. If you do take symmetries of this type into consideration, you'll reduce the number of gamma values you have to compute by a factor of almost 16 (8 symmetries in the D4 group, times 2 colors). This should result in faster learning and better estimates. Álvaro. On Dec 6, 2007 4:28 AM, Lars [EMAIL PROTECTED] wrote: While you can find the gamma-values of non-shape patterns in the paper of Remi, I can give you the list of shape-pattern gamma-values. The source-code is mixed with my engine-code, which i don't like to publish. But the algorithm is more or less easy to implement.. I'll try to attach the file to this mail, if it don't work I send it to your address. The file have the following coding: It's a text-file with one pattern each line. Lines look as: Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n The Pattern-IDs have the following coding: In the binary representation of the ID you have 2 Bits for every field. So you have 18 Bits at all. 00 = Empty, 01 = Black, 02 = White, 03 = Edge The pairs are ordered as: 1 2 3 4 5 6 7 8 9 in the ID it is 123456789 While you can rotate and mirror the patterns only one respresentation of the various possible representations is contained in the file. On Dec 5, 2007 3:17 PM, Lars [EMAIL PROTECTED] wrote: Thank you for your explanations! You were right, it was a bug, and now it works really fine. Are you (or Remi) willing to publish any of the following? 1. Source code for extracting ELO ratings for moves 2. Full list of gamma values, including patterns Either of those would help kick start those of us that are just starting to go down a similar road. ___ 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] ELO Ratings of move pattern
Oh, I see you have applied the symmetries, but not the swapping of roles. Still, this should probably be done and cut the number of gamma values in half. Álvaro. On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote: Thanks for the file! This should be very helpful when I try to reproduce results. It looks like you are not taking advantage of symmetries. For instance, 88|0|17.033168 88|1|12.263955 and 164|0|17.388714 164|1|25.862695 Are identical except for swapping the roles of white and black (88 == 1120 in base 4, 164 == 2210 in base 4), and therefore they should have the same scores. If you do take symmetries of this type into consideration, you'll reduce the number of gamma values you have to compute by a factor of almost 16 (8 symmetries in the D4 group, times 2 colors). This should result in faster learning and better estimates. Álvaro. On Dec 6, 2007 4:28 AM, Lars [EMAIL PROTECTED] wrote: While you can find the gamma-values of non-shape patterns in the paper of Remi, I can give you the list of shape-pattern gamma-values. The source-code is mixed with my engine-code, which i don't like to publish. But the algorithm is more or less easy to implement.. I'll try to attach the file to this mail, if it don't work I send it to your address. The file have the following coding: It's a text-file with one pattern each line. Lines look as: Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n The Pattern-IDs have the following coding: In the binary representation of the ID you have 2 Bits for every field. So you have 18 Bits at all. 00 = Empty, 01 = Black, 02 = White, 03 = Edge The pairs are ordered as: 1 2 3 4 5 6 7 8 9 in the ID it is 123456789 While you can rotate and mirror the patterns only one respresentation of the various possible representations is contained in the file. On Dec 5, 2007 3:17 PM, Lars [EMAIL PROTECTED] wrote: Thank you for your explanations! You were right, it was a bug, and now it works really fine. Are you (or Remi) willing to publish any of the following? 1. Source code for extracting ELO ratings for moves 2. Full list of gamma values, including patterns Either of those would help kick start those of us that are just starting to go down a similar road. ___ 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] cgos
In message [EMAIL PROTECTED], Harri Salakoski [EMAIL PROTECTED] writes Hi is last black move A4 really illegal in cgos rules? Just ensure before start change things. It seemed weird. White D9 shouls change board situation and white kills two stones before A4 is getting then one stone back fine? t. harri W A4 9 WW..W.WWW 8 ...W.W.W. 7 WBW.. 6 WBBWBBWWW 5 .WWWB 4 BWBBB 3 .BBB.B.B. 2 B.B.B 1 . ABCDEFGHJ W D9 9 WW.WW.WWW 8 ...W.W.W. 7 WBW.. 6 WBBWBBWWW 5 .WWWB 4 BWBBB 3 .BBB.B.B. 2 B.B.B 1 . ABCDEFGHJ B A5 9 WW.WW.WWW 8 ...W.W.W. 7 WBW.. 6 WBBWBBWWW 5 BWWWB 4 BWBBB 3 .BBB.B.B. 2 B.B.B 1 . ABCDEFGHJ W A3 9 WW.WW.WWW 8 ...W.W.W. 7 WBW.. 6 WBBWBBWWW 5 .WWWB 4 .WBBB 3 WBBB.B.B. 2 B.B.B 1 . ABCDEFGHJ B A4 9 WW.WW.WWW 8 ...W.W.W. 7 WBW.. 6 WBBWBBWWW 5 .WWWB 4 BWBBB 3 .BBB.B.B. 2 B.B.B 1 . ABCDEFGHJ Here are the positions, edited to make them more legible: W A4 [in fact it is B who has just played A4] O O . . O . O O O . . . O . O . O . O # O . O O O O . O # # O # # O O O . O O O # # # # # # O # # # # # # # . # # # . # . # . # . # # # # # . # # # # # # # # # . W D9 [Note this position, I will refer to it later] O O . O O . O O O . . . O . O . O . O # O . O O O O . O # # O # # O O O . O O O # # # # # # O # # # # # # # . # # # . # . # . # . # # # # # . # # # # # # # # # . B A5 O O . O O . O O O . . . O . O . O . O # O . O O O O . O # # O # # O O O # O O O # # # # # # O # # # # # # # . # # # . # . # . # . # # # # # . # # # # # # # # # . W A3 O O . O O . O O O . . . O . O . O . O # O . O O O O . O # # O # # O O O . O O O # # # # # . O # # # # # # # O # # # . # . # . # . # # # # # . # # # # # # # # # . B A4 O O . O O . O O O . . . O . O . O . O # O . O O O O . O # # O # # O O O . O O O # # # # # # O # # # # # # # . # # # . # . # . # . # # # # # . # # # # # # # # # . If positional superko is in force, this last move is illegal, as it recreates the position noted previously. Nick -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit
On Wed, Dec 05, 2007 at 10:16:20PM -0800, Sylvain Gelly wrote: You should be using area scoring only and if you are playing handicap games then either YOU or MOGO is not counting them the same. Or perhaps Mogo has a bug in the handicap code. MoGo uses KGS handicap counting (add 1 point to white for each handicap stone) if the GTP set_handicap_stones (approximate spelling) is called. By the way, is KGS or SL right here? Is the correct white komi with Chinese counting handicap_number or handicap_number/2? (Note that in case of ING rules, the komi is handicap_number. Perhaps whoever wrote this on the SL page was confused by the fact that half the komi stones are placed in the opponent's territory when counting manually?) -- Petr Pasky Baudis We don't know who it was that discovered water, but we're pretty sure that it wasn't a fish. -- Marshall McLuhan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Re: Update of MoGo binary release, and windows version available! (repost)
Thanks Hideki, Chris and Jacques for your replies.
Hideki wrote:
Then, you can make a very simple program that passes a file to stdout
first and passes stdin to stdout after the end-of-file of the file.
And use it as a.out file | mogo arguments.
Is this not the way a tail -f works?
This is the method I use with gnugo to let te programs play against
each other. The communication between the programs and server program
are all using files. This seems fast enough, while I can check all
the communications which took place.
This tail -f fails in the same way.
To check things even more, I tried to communicate using C with popen():
FILE *ptr;
if ((ptr = popen(mogo --9 --nbTotalSimulations 3000 mogoout, w)) !=
NULL)
{
fprintf(ptr, boardsize 9\n);
fprintf(ptr, genmove b\n);
sleep(60);
}
But the result is the same, after these commands, mogo still continues to
perform multiple genmoves. I am puzzled here...
I will look at the ruby script, and there are also twogtp scripts of gnugo
in python, perl etc. which I could check.
Edward.
_
Probeer Live.nl
Probeer Live.nl: zoekmachine van de makers van MSN! ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] ELO Ratings of move pattern
But then you lose information on player-to-move, right? On Dec 6, 2007 7:18 AM, Álvaro Begué [EMAIL PROTECTED] wrote: Oh, I see you have applied the symmetries, but not the swapping of roles. Still, this should probably be done and cut the number of gamma values in half. Álvaro. On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote: Thanks for the file! This should be very helpful when I try to reproduce results. It looks like you are not taking advantage of symmetries. For instance, 88|0|17.033168 88|1|12.263955 and 164|0|17.388714 164|1|25.862695 Are identical except for swapping the roles of white and black (88 == 1120 in base 4, 164 == 2210 in base 4), and therefore they should have the same scores. If you do take symmetries of this type into consideration, you'll reduce the number of gamma values you have to compute by a factor of almost 16 (8 symmetries in the D4 group, times 2 colors). This should result in faster learning and better estimates. Álvaro. On Dec 6, 2007 4:28 AM, Lars [EMAIL PROTECTED] wrote: While you can find the gamma-values of non-shape patterns in the paper of Remi, I can give you the list of shape-pattern gamma-values. The source-code is mixed with my engine-code, which i don't like to publish. But the algorithm is more or less easy to implement.. I'll try to attach the file to this mail, if it don't work I send it to your address. The file have the following coding: It's a text-file with one pattern each line. Lines look as: Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n The Pattern-IDs have the following coding: In the binary representation of the ID you have 2 Bits for every field. So you have 18 Bits at all. 00 = Empty, 01 = Black, 02 = White, 03 = Edge The pairs are ordered as: 1 2 3 4 5 6 7 8 9 in the ID it is 123456789 While you can rotate and mirror the patterns only one respresentation of the various possible representations is contained in the file. On Dec 5, 2007 3:17 PM, Lars [EMAIL PROTECTED] wrote: Thank you for your explanations! You were right, it was a bug, and now it works really fine. Are you (or Remi) willing to publish any of the following? 1. Source code for extracting ELO ratings for moves 2. Full list of gamma values, including patterns Either of those would help kick start those of us that are just starting to go down a similar road. ___ 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] ELO Ratings of move pattern
Oh, I didn't notice at first that the player-to-move was encoded
seperatly from the pattern shape.
On Dec 6, 2007 9:53 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 6, 2007 9:31 AM, Chris Fant [EMAIL PROTECTED] wrote:
But then you lose information on player-to-move, right?
No. What I am saying is that it is as urgent for black to play on
. . .
. . X
X O .
as it is for white to play in
. . .
. . O
O X .
Precisely one way of implementing what I said is by only storing patterns
with black to move. If it is white's turn, make turn the 01s into 10s and
the 10s into 01s in the pattern and then do the lookup.
Some code like this would do:
unsigned switch_players_in_pattern(unsigned x){
return ((x0x2)1) | ((x0x1)1);
}
Álvaro.
On Dec 6, 2007 7:18 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
Oh, I see you have applied the symmetries, but not the swapping of
roles.
Still, this should probably be done and cut the number of gamma values
in
half.
Álvaro.
On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
Thanks for the file! This should be very helpful when I try to
reproduce
results.
It looks like you are not taking advantage of symmetries. For
instance,
88|0|17.033168
88|1|12.263955
and
164|0|17.388714
164|1|25.862695
Are identical except for swapping the roles of white and black (88 ==
1120
in base 4, 164 == 2210 in base 4), and therefore they should have the
same
scores. If you do take symmetries of this type into consideration,
you'll
reduce the number of gamma values you have to compute by a factor of
almost
16 (8 symmetries in the D4 group, times 2 colors). This should result in
faster learning and better estimates.
Álvaro.
On Dec 6, 2007 4:28 AM, Lars [EMAIL PROTECTED] wrote:
While you can find the gamma-values of non-shape patterns in the
paper
of Remi, I can give you the list of shape-pattern gamma-values.
The source-code is mixed with my engine-code, which i don't like to
publish. But the algorithm is more or less easy to implement..
I'll try to attach the file to this mail, if it don't work I send it
to
your address.
The file have the following coding:
It's a text-file with one pattern each line.
Lines look as:
Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n
The Pattern-IDs have the following coding:
In the binary representation of the ID you have 2 Bits for every
field.
So you have 18 Bits at all.
00 = Empty, 01 = Black, 02 = White, 03 = Edge
The pairs are ordered as:
1 2 3
4 5 6
7 8 9
in the ID it is
123456789
While you can rotate and mirror the patterns only one
respresentation of
the various possible representations is contained in the file.
On Dec 5, 2007 3:17 PM, Lars [EMAIL PROTECTED] wrote:
Thank you for your explanations!
You were right, it was a bug, and now it works really
fine.
Are you (or Remi) willing to publish any of the following?
1. Source code for extracting ELO ratings for moves
2. Full list of gamma values, including patterns
Either of those would help kick start those of us that are just
starting to go down a similar road.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Update of MoGo binary release, and windows version available! (repost)
Edward de Grijs: [EMAIL PROTECTED]:
Thanks Hideki, Chris and Jacques for your replies.
Hideki wrote:
Then, you can make a very simple program that passes a file to stdout
first and passes stdin to stdout after the end-of-file of the file.
And use it as a.out file | mogo arguments.
Is this not the way a tail -f works?
I don't know the way tail -f works but I guess _no_ as tail never
use stdin. That is, the program opens the file at first and copy it
to stdout unitl end-of-file. Then the program closes the file and
opens stdin and copy it to stdout.
This is the method I use with gnugo to let te programs play against
each other. The communication between the programs and server program
are all using files. This seems fast enough, while I can check all
the communications which took place.
This tail -f fails in the same way.
To check things even more, I tried to communicate using C with popen():
FILE *ptr;
if ((ptr = popen(mogo --9 --nbTotalSimulations 3000 mogoout, w)) !=
NULL)
{
fprintf(ptr, boardsize 9\n);
fprintf(ptr, genmove b\n);
sleep(60);
}
But the result is the same, after these commands, mogo still continues to
perform multiple genmoves. I am puzzled here...
I guess above code does not work. Probably MoGo reads the last line
repeatedly when end-of-file occurs.
Hideki
I will look at the ruby script, and there are also twogtp scripts of gnugo
in python, perl etc. which I could check.
Edward.
_
Probeer Live.nl
Probeer Live.nl: zoekmachine van de makers van MSN!
inline file
___
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] ELO Ratings of move pattern
On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote: 88|0|17.033168 88|1|12.263955 and 164|0|17.388714 164|1|25.862695 Are identical except for swapping the roles of white and black Curiously, the gamma values in your example are way different 17.033168 vs 25.862595 and 12.263955 vs 17.388714 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] ELO Ratings of move pattern
On Dec 6, 2007 10:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote: On Dec 6, 2007 10:06 AM, Jason House [EMAIL PROTECTED] wrote: On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote: 88|0|17.033168 88|1|12.263955 and 164|0|17.388714 164|1|25.862695 Are identical except for swapping the roles of white and black Curiously, the gamma values in your example are way different 17.033168 vs 25.862595 and 12.263955 vs 17.388714 That was exactly my point. Those should theoretically be identical, which means that the difference comes purely from noise. The games that were used for training probably don't have enough examples of these patterns to get a good estimate of their true strength. This may serve as a good test of if there is enough data to assign values to the patterns. Actually, the gamma values are only determined up to a multiplication of all of them by a constant. Because patterns with white to move and patterns with black to move never compete with each other, they may have drifted in such a way that the discrepancy is not as large as it seems (since both ratios 25.862595/17.033168 and 17.388714/12.263955 are similar). That may be a fluke. Other pairs have a much different ratio 0|0|1.463386 0|1|1.337276 Still, forcing those gamma values to be identical seems like the right thing to do. I agree ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re[2]: [computer-go] ELO Ratings of move pattern
Yes! You are write. I haven't mentioned this. It's a good idea to swap them all in the form that black has the move-right. Thank you! I'll fix that. But not today ;) If you find any inconsistencies in the data please let me know! By the way: I forgot to cut the file at the end. You should only use the values of pattern with an ID 0x4. ÁB Thanks for the file! This should be very helpful when I try to reproduce results. ÁB It looks like you are not taking advantage of symmetries. For instance, ÁB 88|0|17.033168 ÁB 88|1|12.263955 ÁB and ÁB 164|0|17.388714 ÁB 164|1|25.862695 ÁB Are identical except for swapping the roles of white and ÁB black (88 == 1120 in base 4, 164 == 2210 in base 4), and therefore ÁB they should have the same scores. If you do take symmetries of ÁB this type into consideration, you #39;ll reduce the number of ÁB gamma values you have to compute by a factor of almost 16 (8 ÁB symmetries in the D4 group, times 2 colors). This should result in ÁB faster learning and better estimates. ÁB Álvaro. ÁB On Dec 6, 2007 4:28 AM, Lars [EMAIL PROTECTED] wrote: ÁB While you can find the gamma-values of non-shape patterns in the paper ÁB of Remi, I can give you the list of shape-pattern gamma-values. ÁB The source-code is mixed with my engine-code, which i don #39;t like to ÁB publish. But the algorithm is more or less easy to implement.. ÁB I #39;ll try to attach the file to this mail, if it don #39;t work I send it to ÁB your address. ÁB The file have the following coding: ÁB It #39;s a text-file with one pattern each line. ÁB Lines look as: ÁB Pattern-ID|Move-right(0=black, 1=white)|gamma-value\n ÁB The Pattern-IDs have the following coding: ÁB In the binary representation of the ID you have 2 Bits for every field. ÁB So you have 18 Bits at all. ÁB 00 = Empty, 01 = Black, 02 = White, 03 = Edge ÁB The pairs are ordered as: ÁB 1 2 3 ÁB 4 5 6 ÁB 7 8 9 ÁB in the ID it is ÁB 123456789 ÁB While you can rotate and mirror the patterns only one respresentation of ÁB the various possible representations is contained in the file. On Dec 5, 2007 3:17 PM, Lars [EMAIL PROTECTED] wrote: Thank you for your explanations! You were right, it was a bug, and now it works really fine. Are you (or Remi) willing to publish any of the following? 1. Source code for extracting ELO ratings for moves 2. Full list of gamma values, including patterns Either of those would help kick start those of us that are just starting to go down a similar road. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ÁB ___ ÁB computer-go mailing list ÁB computer-go@computer-go.org ÁB 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] Re: The global search myth
As any incomplete search, it can blunder, but why more than any other incomplete search? Not worse, just not a magic bullet. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo and handicap matching
Lavergne Thomas wrote: If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. Here are the issues. You want to know how good a 19x19 HUMAN 1 dan player would do on CGOS playing 9x9.This is because there is no real ranking system for 9x9 and yet you would like to be able to say that program xyz plays 2 dan strength, even though the ranking system wasn't really designed for 9x9 Go. We just need a point of reference so that we can say in general terms that a program like Mogo on CGOS is playing 2 dan strength (or whatever it really is.) But most of us feel that you cannot do this with GO programs - you need humans. For instance you could take GnuGo, get a 19x19 rating and then play on 9x9 CGOS and use it as a reference point.However GnuGo was not designed to play 9x9 go. My own program Lazarus is terrible at 19x19 but pretty good at 9x9. It could probably give a low kyu player a really good game on 9x9 but it would be easily beat at 19x19 - so it's not a good way to standardize.I believe GnuGo is more balanced in this way - but it's probably a bad idea in general to figure it this way. Your idea is fine for 19x19 CGOS. - Don Tom On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote: The only issue is that I don't know if GnuGo is representative of 19x19 to 9x9 go strength. I am interested in knowing how a human 19x19 scales down to 9x9 play. It's well known that programs scale up poorly. However, this data should still be quite useful. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
I understand that Monte Carlo algorthms are driven by the winning probability, and a 0.5 win looks as good - or maybe even better - than a 100-point win. However, the estimated probability of winning may be way off. It is well known that Mogo, and perhaps some other programs, fail to recognize common nakade placements, which leads to fundamental estimation errors. An algorithm with more of a fighting spirit would defend against nakade, and attack enemy groups; perhaps making up for the loss of one group by the capture of another. Any algorithm which drives the win toward 0.5 is always going to be brittle; any problems with the accuracy of the evaluation may place one on the losing side of that 0.5 divide. Hence, if it is possible to be more greedy - to seal off groups, to play for every yose point, to fill in dame first - programs based on monte carlo will improve. It's terrible to lose a won game by drifting over the edge of a precipice. When monte carlo programs lose, they lose big -- in my so-far limited observations, incorrect evaluation of life-and-death status leads to estimation errors which far exceed the 0.5 margin of error. For a large number of playouts, the estimated scores should converge as the game progresses. This is particularly true if the random distributions strongly favor moves where each opponent monotonically increases the score - keeping one's groups alive, keeping the opponent dead, and growing areas wherever possible. Of course there must be enough variability to permit sacrifice plays and nakade placements; throwing a stone into a group will initially look like a bad play, but if the placement succeeds, it is a very good play, the success of which must be properly attributed to the earlier placement - or even further back, to the surrounding and cutting and eye-killing moves which ultimately led to the placement move. Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo and handicap matching
If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. Tom On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote: The only issue is that I don't know if GnuGo is representative of 19x19 to 9x9 go strength. I am interested in knowing how a human 19x19 scales down to 9x9 play. It's well known that programs scale up poorly. However, this data should still be quite useful. - Don -- Thomas LavergneEntia non sunt multiplicanda praeter necessitatem. (Guillaume d'Ockham) [EMAIL PROTECTED]http://oniros.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Elo and handicap matching
I suggest to make the bots play on kgs but on 9x9 versus human, so we could known approximatively the level of theses bots against human. We can also know the relative strenght of these bots against other bots on cgos in the same conditions (i.e. board size, timing, rules...) so we could estimate the level of all the bots against human. I don't want to mix 19x19 and 9x9. This is far from perfect because human ranks was not fixed on 9x9 but on 19x19, but I think for humans ranks on both size are corelated. As preivously said by me and others humans ranks on 9x9 are not fully corelated on 9x9 and 19x19, I known some people whom I can give 4 or 5 stones on 19x19 but beat me on 9x9 on even games because they practised a lot more than me at this size, but on kgs theses ranks are roughly corelated. Tom On Thu, Dec 06, 2007 at 02:05:39PM -0500, Don Dailey wrote: Lavergne Thomas wrote: If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. Here are the issues. You want to know how good a 19x19 HUMAN 1 dan player would do on CGOS playing 9x9.This is because there is no real ranking system for 9x9 and yet you would like to be able to say that program xyz plays 2 dan strength, even though the ranking system wasn't really designed for 9x9 Go. We just need a point of reference so that we can say in general terms that a program like Mogo on CGOS is playing 2 dan strength (or whatever it really is.) But most of us feel that you cannot do this with GO programs - you need humans. For instance you could take GnuGo, get a 19x19 rating and then play on 9x9 CGOS and use it as a reference point.However GnuGo was not designed to play 9x9 go. My own program Lazarus is terrible at 19x19 but pretty good at 9x9. It could probably give a low kyu player a really good game on 9x9 but it would be easily beat at 19x19 - so it's not a good way to standardize.I believe GnuGo is more balanced in this way - but it's probably a bad idea in general to figure it this way. Your idea is fine for 19x19 CGOS. - Don Tom On Tue, Dec 04, 2007 at 05:30:15PM -0500, Don Dailey wrote: The only issue is that I don't know if GnuGo is representative of 19x19 to 9x9 go strength. I am interested in knowing how a human 19x19 scales down to 9x9 play. It's well known that programs scale up poorly. However, this data should still be quite useful. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Thomas LavergneEntia non sunt multiplicanda praeter necessitatem. (Guillaume d'Ockham) [EMAIL PROTECTED]http://oniros.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
From: terry mcintyre [EMAIL PROTECTED] For a large number of playouts, the estimated scores should converge as the game progresses. This is particularly true if the random distributions strongly favor moves where each opponent monotonically increases the score - keeping one's groups alive, keeping the opponent dead, and growing areas wherever possible. Of course there must be enough variability to permit sacrifice plays and nakade placements; throwing a stone into a group will initially look like a bad play, but if the placement succeeds, it is a very good play, the success of which must be properly attributed to the earlier placement - or even further back, to the surrounding and cutting and eye-killing moves which ultimately led to the placement move. --- expanding my own email: Is it possible to cache the results of life-and-death analysis for use by playouts, so that dead groups stay dead, live groups stay alive, areas increase, and players tend to efficiently improve the status of their own groups ( and demote the status of the opponents' ) wherever that is feasible? Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
Any estimate of winning probability is only as good as the estimates of whether particular games are actually won or lost. Evidently, even strong programs fail to recognize the impact of nakade, which will alter the score not by one point, but by ten or twenty. Their estimate of winning probability is totally wrong. Good players winnow out losing moves and stick with good moves - the basic premise of minimax searching. Losing a big group will lead to a win only if one obtains equivalent compensation elsewhere. Good players sometimes make sacrifice plays, but failing to recognize that one's group is lost will totally skew one's estimate of one's winning chances. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
On Thu, 2007-12-06 at 14:21 -0500, Don Dailey wrote: However, the estimated probability of winning may be way off. It is well known that Mogo, and perhaps some other programs, fail to recognize common nakade placements, which leads to fundamental estimation errors. An algorithm with more of a fighting spirit would defend against nakade, and attack enemy groups; perhaps making up for the loss of one group by the capture of another. Any algorithm which drives the win toward 0.5 is always going to be brittle; It doesn't drive the win towards 0.5.It doesn't view them as any differently. However, they will prefer a bigger win if there is any room for error.Usually a bigger win is a more likely win - it's only in the cases where it isn't that Monte Carlo program do not care. This is a fundamental error in how people think about this. Your intuition is that you should try for a bigger win just in case - or that it improves your overall winning chances.But if 10,000 monte carlo playouts see one line as winning 10,000 times and another line as winning 9,999 times, even if most of those wins are BIG, it will choose the sure thing. And maybe that cause them to lose more games. I understand the appeal of an elegant solution, but until we have such computing power that MC is practically identical to a complete game search, they will sometimes miss things, things that lose them a lot of points, or things that lose them some points. The latter doesn't matter if it has a significant lead that it hasn't thrown away. Another way to look at it is this: If there are 2 key groups being fought over, and winning either one wins the game, it will choose the group that it is MOST likely to win - even if it is far smaller. There really is no way to improve on this except to trick it into NOT maximizing it's winning probability. You might end up with a program that appears to play more human, but it will sacrifice some playing strength. Why would it lose playing strength by hedging its bets on making mistakes? Right now, if it plays under the assumption that it makes no mistakes (0.5 margin is enough to win the game), then some percentage X of the games will be lost because it misses things. If it plays under the assumption that it might make mistakes worth Y points (thus play as if a Y+0.5 point margin is needed to win the game), then it will in some percentage of games Z lose because it played too risky, took chances it didn't have to. If XZ for all Y, then you are right. I don't think you are. The best strategy is probably to vary Y across the game, based on heuristics that are good at spotting situations where MC tend to miss things. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: evaluating monte carlo results
At 11:39 AM 12/6/2007, terry mcintyre wrote: Any estimate of winning probability is only as good as the estimates of whether particular games are actually won or lost. I propose that monte carlo programs should produce a distribution of quantitative outcomes rather than just a simple %win. It's only a very little more information to collect if you bin the outcomes in 10 point increments. Given this kind of data, you could prefer moves that had a narrower distribution of outcomes, and positively avoid those with bimodal distributions where 51% win big and 49% lose big. .. or it might be found that the distribution of outcomes is not a usable factor. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
In message [EMAIL PROTECTED], terry mcintyre [EMAIL PROTECTED] writes Any estimate of winning probability is only as good as the estimates of whether particular games are actually won or lost. Evidently, even strong programs fail to recognize the impact of nakade, MC programs don't even have any concept of nakade. Nevertheless, the best of them are stronger than programs that do. which will alter the score not by one point, but by ten or twenty. Their estimate of winning probability is totally wrong. Good players winnow out losing moves and stick with good moves - the basic premise of minimax searching. Losing a big group will lead to a win only if one obtains equivalent compensation elsewhere. Good players sometimes make sacrifice plays, but failing to recognize that one's group is lost will totally skew one's estimate of one's winning chances. We all know that MC programs don't play perfectly. What point are you making? Nick -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Where and How to Test the Strong Programs?
On Tue, 4 Dec 2007, Christoph Birk wrote: On Tue, 4 Dec 2007, Don Dailey wrote: It would be awkward at best. I could build a client to do this, but the human would have to be willing to sit and play games at the moment they were scheduled. You are right ... it's very awkward. I lost one game by typo and another by time. I added a simple GUI to my program to play on CGOS ... but I am not doing very well :-( Any (dan) volunteer(s) ? Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Where and How to Test the Strong Programs?
Christoph Birk wrote: On Tue, 4 Dec 2007, Christoph Birk wrote: On Tue, 4 Dec 2007, Don Dailey wrote: It would be awkward at best. I could build a client to do this, but the human would have to be willing to sit and play games at the moment they were scheduled. You are right ... it's very awkward. I lost one game by typo and another by time. I added a simple GUI to my program to play on CGOS ... but I am not doing very well :-( Any (dan) volunteer(s) ? Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ I noticed handtalk on CGOS. Does anybody knows if it is the Chinese program ? I thought it may be a human player, because it does not play so many games in a row, and appeared when we talked about gtpdisplay. If it is really the Chinese HandTalk program, then it is stronger than I would have expected of a classical program. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
From: Nick Wedd [EMAIL PROTECTED] which will alter the score not by one point, but by ten or twenty. Their estimate of winning probability is totally wrong. Good players winnow out losing moves and stick with good moves - the basic premise of minimax searching. Losing a big group will lead to a win only if one obtains equivalent compensation elsewhere. Good players sometimes make sacrifice plays, but failing to recognize that one's group is lost will totally skew one's estimate of one's winning chances. We all know that MC programs don't play perfectly. What point are you making? I begin with the empirical observation that existing MC programs can be very wrong in their estimation of the likely score of given positions, and therefore of the winning probabilities of the various moves. Consider a group which dies due to a skillful placement. If I know about this irrefutable move, I estimate that your group is dead, and the score is 20 points in my favor. If I do not know that move, my estimate might be that the game is yours by half a point. Now, in a universe of equally blind bots, a poor estimate can be better than a slightly worse estimate; but to compete against pro human players, one must be able to get fairly close to the correct score for stable positions. My point is that there appears to be a systemic error in the existing estimation process. Relating back to the move generation used by random playouts; amongst skilled players, it is quite common to consider ways to reduce groups to the single-eyed state. ( The Cotsen Go Tournament sweatshirts read Cyclops Assassin for this reason. ) Under fast time controls, humans may fail to notice some nakade opportunities. It is also possible to exploit nakade, but to have a bot continue playing as if it were still in the game, eventually winning on time. When human players discover that it is important to explicitly kill such groups, the winning rates of such bots will plummet. I suggest that a useful stage in the evolution of heavy playouts might be to incorporate provably-correct analysis of group status, placements, and fighting spirit heuristics. This would skew the distribution of playouts toward that actually used by skilled players, improving the accuracy of the estimation. As my friend and coach Chris H often says: When in doubt, read it out. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: low-hanging fruit - yose
Here's a more likely scenario: Approaching endgame, there are 10 resolved fights that remain to be played out. The program estimates is won 5 of them and lost 5 of them, each with 85% confidence. The sizes of the groups is such that any single switch from won to lost will swing the game. The probability of one such flip is pretty high. If one of the groups is much larger, you should go for the big group, because if it switches, the game is flipped irrevocably, whereas if one of the small groups flips, it might be corrected by switching status of another group. That's why you should play for the big win, or to avoid the big loss. It swamps all the other uncertainties. Of course, current programs don't see the situation with anything approaching this level of analysis, but given a choice or a big win or a small win with slightly higher probability, I suspect that detailed analysis would be similar to the above. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] low-hanging fruit - yose
You can't play to win if you don't actually know whether you are winning or losing. Analyze any lost game, and the loser will admit I didn't see that coming - they were playing an imaginary game, not the one actually on the board. Some are honest enough to admit: I was hallucinating there. We're not talking about 85% of this and 80% of that; we're talking about groups which are 100% dead, irrefutably dead, get the casket and buy the flowers and fire the salutes, it's smelling rotten already, versus programs which assign a 90% estimation of winning the game, buying fireworks and Xmas presents to celebrate for this move and the next until ... Ooops! Is my witty bitty group dead? Whatever were we thinking? Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] programs at the US Go Congress
I organized the go congress computer go tournaments for many years. Ask the AGA congress organizers for prize money. The congress has a big pool of prize money. Several years I convinced the organizers to put up $500 to $1000 in prize money. Usually the congress budget isn't set until right before it starts, so they never committed to prize money until the start of the congress. Ask the congress organizer about machines. The congresses are at colleges, which will have computer labs. Sometimes they are willing to let us use the computer lab for a couple of days. Most participants brought their own machine in the more recent years, after laptops became inexpensive, so you might not need computers. I used to run the tournament on Monday and Tuesday, since Wednesday is a day off, and an early tournament lets the go players concentrate on the congress human tournaments after the go tournament is over. I ran a round robin or double round robin. That way you can start games as soon as opponents are ready and the tournament is over much quicker. I suggest publishing rules ahead of time to avoid conflicts, and appoint someone to be tournament director in case of disputes. You should probably plan to support both modem protocol and gtp. Gtp requires a referee computer, so you will have to bring one extra. I plan to go to the European congress in Sweden, which should have a computer competition. I think it conflicts with the US congress, so I don't think I'll be there. David Here is the rules and announcement from the last tournament I organized: 1996 UNITED STATES COMPUTER GO CHAMPIONSHIP .S -2 .R This announces the 1996 U.S. Computer Go Competition. The 1996 US Computer Go Championship will take place at the 16th annual US Go Congress, on July 21, 22, 23rd, at John Carrol University, in Cleveland, Ohio. This is an excellent opportunity to meet and compete with others interested in Computer Go. A plaque or trophy and title of US Computer Go Champion will be awarded to the winner. There is no cash prize. This tournament is not affiliated with the World Computer Go Congress, although the rules and format are very similar. In 1988 and 1989 Acer ran the US Preliminaries to the World Computer Go Congress at the US Go Congress. In 1990 they changed their procedure to have a mail in preliminary in Taiwan. The United States Computer Go Championship was organized to ensure that there continues to be an annual computer go competition in North America. The informal discussions and contacts during the tournament help increase the strength of all the programs. This will be the seventh United States Computer Go Championship. Last year 4 programs participated. Typically 5 to 7 programs compete. . ENTERING THE CONTEST: . You must register for the US Go Congress to enter the Computer Go Competition. Please contact David Fotland as soon as possible if you plan to participate. There is no penalty for withdrawing from participation later. I prefer early notice of participation, but will accept new participants up to the day before the competition. For additional information on the Computer Go contest, contact: David Fotland 4863 Capistrano Ave San Jose Ca 95129-1031 (408)985-1236 E-mail: [EMAIL PROTECTED] RULES Contestants must provide their own computer, which must be present at the contest site. All transportation costs and risks will be borne by the contestant. There will be a locked room for the contest, but the Congress will not be responsible for the safety of any equipment left there. This year there may be some computer hardware available, but at this time I can't promise anything. Any Go program can participate in the contest, but only US programs whose author(s) are US residents are eligible for the title of US Computer Go Champion. The title of North American Open Computer Go Champion will be awarded to the program that finishes first, no matter where it is from. Each program can only be registered once. Play is governed by the SST laws of Go (GOE) published by the Ing Chang Chi Wei Chi Educational foundation. In summary, the score is territory plus live stones (prisoners don't count), suicide of more than one stone is allowed, repetition is forbidden, surrounded territory in a seki counts as points. Black plays first and gives 8 points komi at the end of the game. If a program makes an illegal move it loses. Mirror Go is not allowed past move number 60. Any rule disputes will be settled by the tournament referee. There will be a Go board between the computers which will have the official game position. If a move is entered incorrectly the problem may be fixed while the clock is running. If the participant is unable to correct his program to agree with the position on the Go board, the participant loses. Programs should be able to remove dead stones from the screen or demonstrate that the dead stones are recognized at the end of the game. If both programs
Re: [computer-go] Re: evaluating monte carlo results
-Original Message- From: Jason House [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thu, 6 Dec 2007 4:44 pm Subject: Re: [computer-go] Re: evaluating monte carlo results On Dec 6, 2007 4:22 PM, [EMAIL PROTECTED] wrote: My program is riddled with code to try and make use of this. (It's always bothered me that UCT relies on the ? standard deviation of (often) multi-modal distributions.) It hasn't made my engine any stronger but it has helped? me understand some things better. Care to elaborate on what you've come to learn?? I too have discomfort with some of the ways UCT works. If I start from an empty board and make a histogram of the final scores of random playouts, it tells me a bit about my playout algorithm. Smarter playout algorithms lead to lower (IIRC) required komis. From a root node, looking at the tails of the histogram of final scores tells me something about how much can potentially be gained by applying the mercy rule and where to set the threshold. It seems reasonable to suppose that for a root node where the distribution of outcomes is changing rapidly (the peaks moving around) or has widely separated peaks, maybe it should still be exploring more, or maybe it just needs more time, this turn, to settle. I personally haven't gotten any traction here but wouldn't be too surprised if someone else has more luck. It gets into issues of whether any margin of victory is very significant. I notice the why don't we make UCT just a little greedier discussion has cropped up yet again. I've tried that both ways, as have many others here. More new features than ever. Check out the new AIM(R) Mail ! - http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp000501 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] winning a won game
In message [EMAIL PROTECTED], terry mcintyre [EMAIL PROTECTED] writes I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so I'll just rest my argument What _is_ your argument? Nick with the chapter headings from his book, Winning a Won Game: Chapter 1 Three Golden Rules *Avoid uncertainties when you have the lead *Seize the opportunity when it is presented *Attack the opponent's weakness and deliver the fatal blow Chapter 2 Seven Examples of Success *Avoid battle while ahead *Grasp the opportunity and attack vigorously *Claim victory by invading *Counterattack when your opponent tries to claim victory *Do not back off even slightly in close games *Do not let any opportunity slip away *Use the splitting attack What's good enough for him, should be fair enough for the rest of us ... now to determine who to convert these maxims to robust code. Looking for last minute shopping deals? Find them fast with Yahoo! Search. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo rank on 9x9 on kgs
Le jeudi 6 décembre 2007, Don Dailey a écrit : Lavergne Thomas wrote: If some bot can be setup to play on kgs for enough time to get a solid rank and then put on cgos to get an elo rating with the same configuration we could find a formula to convert elo to kgs ranks. For sure, this is not perfect but I think is good enought. But most of us feel that you cannot do this with GO programs - you need humans. For instance you could take GnuGo, get a 19x19 rating and then play on 9x9 CGOS and use it as a reference point.However GnuGo was not designed to play 9x9 go. My own program Lazarus is terrible at 19x19 but pretty good at 9x9. It could probably give a low kyu player a really good game on 9x9 but it would be easily beat at 19x19 - so it's not a good way to standardize.I believe GnuGo is more balanced in this way - but it's probably a bad idea in general to figure it this way. Your idea is fine for 19x19 CGOS. - Don I used 946 9x9 games of my gnugo bot on kgs: On 9x9 it appears that gnugo _has_ the same rank as on 19x19. So just giving standard gnugo a fixed kyu on cgos (lets say 6k like kgs) should give rather good estimation. /Alain PS: Here are the histograms for my ranked bots on kgs, for those who wants to do more subtle estimation and cannot wait monthes before their bot gathered enough games on kgs :) (these are old games before ranking system changes, so gnugo 3.7.9 and 10 were 13k kgs, they are now 6k) I filtered out handicap games and unfinished, but did not check cheaters. The tables are #occurence #opponent_rank(kgs_old_kyu) For komi 7 and 7.5 gg99_rank/km7$ cat black_lose_agaisnt.csv 1 2 1 10 2 13 gg99_rank/km7$ cat black_wins_agaisnt.csv 1 10 1 12 2 13 gg99_rank/km7$ cat white_wins_agaisnt.csv 1 2 3 9 1 10 1 11 19 12 44 13 2 15 4 16 3 18 2 19 1 20 2 21 2 25 2 26 4 30 gg99_rank/km7$ cat white_lose_agaisnt.csv 1 3d 1 2 5 9 2 10 1 11 4 12 47 13 1 14 2 16 1 17 2 18 1 19 1 21 2 25 6 30 For komi 0 and 0.5 : gg99_rank/km0$ cat black_wins_agaisnt.csv 1 5 1 6 13 7 14 8 16 9 11 10 34 11 50 12 2 14 3 17 1 18 1 24 1 30 gg99_rank/km0$ cat black_lose_agaisnt.csv 1 3 1 4 2 5 1 6 6 7 11 8 17 9 5 10 23 11 23 12 1 17 1 20 gg99_rank/km0$ cat white_wins_agaisnt.csv 28 12 211 13 5 25 1 30 gg99_rank/km0$ cat white_lose_agaisnt.csv 31 12 245 13 1 14 2 16 1 17 1 22 4 25 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] winning a won game
I propose a far more powerful and correct set of rules: 1. Play the move that gives you the best chance of winning. Unfortunately, that it not very helpful for humans. Luckily it is helpful for a UCT engine or a similar best first + MC engine. On Dec 6, 2007 6:29 PM, terry mcintyre [EMAIL PROTECTED] wrote: I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so I'll just rest my argument with the chapter headings from his book, Winning a Won Game: Chapter 1 Three Golden Rules Avoid uncertainties when you have the lead Seize the opportunity when it is presented Attack the opponent's weakness and deliver the fatal blow Chapter 2 Seven Examples of Success Avoid battle while ahead Grasp the opportunity and attack vigorously Claim victory by invading Counterattack when your opponent tries to claim victory Do not back off even slightly in close games Do not let any opportunity slip away Use the splitting attack What's good enough for him, should be fair enough for the rest of us ... now to determine who to convert these maxims to robust code. Looking for last minute shopping deals? Find them fast with Yahoo! Search. ___ 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] winning a won game
Hi Terry, How to convert these maxims to robust code? Use monte carlo with win/loss scoring as we do now.These maxims fit the monte carlo scoring model perfectly. - Don terry mcintyre wrote: I am hardly fit to clean the dust from Pro 9-dan Go Seigen's goban, so I'll just rest my argument with the chapter headings from his book, Winning a Won Game: Chapter 1 Three Golden Rules * Avoid uncertainties when you have the lead * Seize the opportunity when it is presented * Attack the opponent's weakness and deliver the fatal blow * Chapter 2 Seven Examples of Success Avoid battle while ahead * Grasp the opportunity and attack vigorously * Claim victory by invading * Counterattack when your opponent tries to claim victory * Do not back off even slightly in close games * Do not let any opportunity slip away * Use the splitting attack What's good enough for him, should be fair enough for the rest of us ... now to determine who to convert these maxims to robust code. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ 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] low-hanging fruit - yose
Any estimate of winning probability is only as good as the estimates of whether particular games are actually won or lost. Evidently, even strong programs fail to recognize the impact of nakade, MC programs don't even have any concept of nakade. Nevertheless, the best of them are stronger than programs that do. Just replying to this point, not the main theme of the thread, but there are two things here: 1. Random playout MC/UCT programs have no concept of nakade. But they don't have the nakade weakness either. They are bad players, but pure. 2. Mogo (and CrazyStone) are using lots of intelligence in their playouts, and that is the cause of the nakade weakness. They are good players, but they have preconceptions. They consider the moves required to discover the difference between a nakade and dead-stones-in-a-definitely-alive-group as low priority. So, in that sense, they do have a concept of nakade. (I hope Remi, or one of the Mogo developers, will correct me if I've misunderstood what is going on.) Darren -- Darren Cook http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) http://dcook.org/work/ (About me and my work) http://dcook.org/work/charts/ (My flash charting demos) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GPUs and go algorithms?
Joshua Shriver wrote: I've been looking into GPGPU for several years now, there was even some buzz in the comp-chess stream but the downsides seemed to be to much. Think the big problem is the latency on the PCI/AGP bus. Though that might not be as much an issue now with PCI-x, etc. Thanks. My question could've been rephrased as Can a basic alpha-beta searcher for chess be written to run on a GPU?. Can I take the above to mean Yes, but the overhead of calling it took too much time? Or were they putting some smaller part of the chess algorithm (e.g. leaf node evaluation or move sorting) on the GPU? (In which case I can see how communication overhead would drown out the performance gain.) For more info I'd refer you to this site which has been using GPU's for years. http://www.gpgpu.org/ Thanks, yes, that is a useful site. However I don't see anything related to tree search. Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GPUs and go algorithms?
I've been looking into GPGPU for several years now, there was even some buzz in the comp-chess stream but the downsides seemed to be to much. Think the big problem is the latency on the PCI/AGP bus. Though that might not be as much an issue now with PCI-x, etc. For more info I'd refer you to this site which has been using GPU's for years. http://www.gpgpu.org/ -Josh On Dec 6, 2007 7:32 PM, Darren Cook [EMAIL PROTECTED] wrote: An interesting article on using GPUs for general purpose computation: http://www.linux-mag.com/microsites.php?site=business-class-hpcsid=buildp=4543 In (current mainstream) computer go there are two main CPU-bound algorithms: playouts (random, or incorporating logic or patterns) and tactical search. But the GPUs seem even more restricted in what they can do than the PS3 Cell processors (where the main restriction there was only a small amount of local memory). E.g. from the above article: * No stack or heap * No integer or bit-wise operations * No scatter operations (a[i]=b) * No reduction operations (max(), min(), sum()) On the other hand this quote [1] from the Sh language page says it has for/if statements, which the latest GPUs support. Does anyone here both understood the above go algorithms *and* had experience with programming GPUs, and can confirm that they are not really useful? Darren [1]: From http://www.libsh.org/about.html Sh incorporates full language constructs for branching (e.g. for loops and if statements). Once GPUs are powerful enough to execute such constructs (which, to some extent, is true today) backends can be adjusted to compile such code to real hardware assembly. In the mean time our GPU simulator Sm implements various features expected to be in GPUs in the near future, such as a unified vertex and fragment instruction set. -- Darren Cook http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) http://dcook.org/work/ (About me and my work) http://dcook.org/work/charts/ (My flash charting demos) ___ 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] low-hanging fruit - yose
2. Mogo (and CrazyStone) are using lots of intelligence in their playouts, and that is the cause of the nakade weakness. They are good players, but they have preconceptions. They consider the moves required to discover the difference between a nakade and dead-stones-in-a-definitely-alive-group as low priority. So, in that sense, they do have a concept of nakade. There's more Go-expertise tricks in crazystone than in mogo, as far as I see in Remi's papers. The Go-expertise in mogo is a very (possibly too much) small number of lines of codes. Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
