[computer-go] Scoring - step function or sigmoid function?
It seems to be surprisingly difficult to outperform the step function when it comes to mc scoring. I know that many surprises await the mc adventurer, but completely discarding the final margin of victory just can't be optimal. The sigmoid function can be tinkered with ofcourse, by making its slopes steeper and/or by awarding bonus points for victory. But if it looks like the step function in the end, then computational resources could have been saved by just using the step function from the start. The power of the step function is that it directly awards what we are really interested in - victory. And an mc program, holding on to a half point victory in the endgame, is a thing of beauty and terror. But in the opening, where the scoring leaves are 300 moves away from the root, surely a putative half point win doesn't translate to a significant advantage, where as a 100 point win would. My suggestion is this: how about backing up the individual outcomes through the tree and then do the evaluation at the intermediate nodes, using the sigmoid function and the parameters depending on the distance from the root? This might be too expensive computationaly, but shortcuts could be devised. For example, wins could be sorted into a couple of different categories( from half point win to landslide), and those categories could be evaluated differently, depending on the distance to the root. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] KGS bot tournaments
I have set the dates for the next two KGS bot tournaments - Sunday July 19th, and Sunday August 9th. They are listed at http://www.weddslist.com/kgs/future.html I am alternating the times between major timezones, so have not alternated the board sizes. I may decide to hold twice as many 19x19 as 9x9 events. I felt that last weekend's 19x19 event with the fastish setting of 18 minutes each worked well. The programs played better than I do, despite none of them being highly parallel. So I am repeating this setting for the next event (increasing it marginally to 19 minutes). Nick -- Nick Weddn...@maproom.co.uk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] self-play inflation
I tested slef-play, and vs GNU Go by my program Aya. 9x9 result is from 1000 games. 19x19 result is from 349 - 550 games. If GNU Go is anchor in 19x19, my 2 playout version will get +195 elo. If Aya is anchor, it will get +488 elo. The difference is not small. 9x9 Aya self-play (against 360 playout/move) result winning rate, games 0.500 360 playout 0.714 1000 720 playout +159 elo 0.865 1000 1440 playout +323 elo 9x9 Aya vs GNU Go 3.7.10 result 0.488 1000 360 playout 0.633 1000 720 playout +104 elo 0.753 1000 1440 playout +203 elo 19x19 Aya self-play (against 5000 playout/move) result 0.500 --- 5000 playout 0.807 369 1 playout +249 elo 0.943 509 2 playout +488 elo 19x19 Aya vs GNU Go 3.7.10 0.538 401 5000 playout 0.676 550 1 playout +101 elo 0.782 349 2 playout +195 elo Regards, Hiroshi Yamashita ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: fuego strength
On Wed, Jun 24, 2009 at 12:39:05PM -0400, Jason House wrote: That raises an interesting point. I've also put bots up in a setup and forget scenario, but inevitably the bit is off of CGOS within a few days and I had no idea when it went down. What's the right way to solve this issue so such altruistic bots can be more easilly maintained? This may also help the anchor absence issue too. If cgosclient not only stall but really crash (due to itself, your program or more probably a network failure) you can just put it in script with a loop : runme.sh: #!/bin/sh while true do cgosclient done I've done this in the past and it works well. I suppose you can do something similar on Windows, but as I know almost anything about windows I can't you for it. I recomand putting a 'mail' in the loop for sending you informations about the crash. And to be gently with the server, adding a 'sleep x' in order to wait a bit before reconnecting. Tom -- Thomas LavergneEntia non sunt multiplicanda praeter necessitatem. (Guillaume d'Ockham) thomas.laver...@reveurs.orghttp://oniros.org ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Complicated seki with Ko
Here is a position that exposed some bugs in Pebbles. Maybe it will help you. 1 2 3 4 5 6 7 8 9 A - O - O X - - X - B - X O - O X - O O C - O O - O - X O - D X X X O O O O O O E - O X X X O X O O F - - O X O X X X X G - - X X O O X X - H - O X O - O O X X J - O X O O - X - X X to play. X is already doomed in this position. The bottom O group is in a seki with the X group at right. O cannot play J6 self-atari. X cannot fill in J8 and then play J6, and after X J6, O captures and X cannot recapture. So it will be dual life. Because the top of the board is O's, O have more than half the board, even without komi. The playouts have to handle certain issues well in order to find that. The first point is to filter out plays that make self-atari on large groups. This will cause the rest of the board to fill up until only the seki remains. The the playout will be in a position like the following: 1 2 3 4 5 6 7 8 9 A - O - O O - O O - B O - O - O O - O O C - O O - O - O O - D X X X O O O O O O E - X X X X O X O O F X X - X O X X X X G X - X X O O X X - H X X X O - O O X X J X - X O O - X - X X to play. Pebbles does not detect superko in playouts, so this position will loop forever with J6/J8/J7/pass. In Pebbles, infinite games were scored as draws. I changed that to give the win to O on the basis of its preponderance of material. (No doubt that will bite me at some point.) Even if we detect the superko repetition, it seems to me that we are only getting the right answer by accident. For instance, if X plays J6 then after J8/J7 there is no move for X, so X has self-ataried himself. Another possibility if to see that X's J6 is atari and also self-atari, so X can look for the approach move. In this case X would play J8 instead of J6 which avoids the ko. Then the seki is obvious. How do other programs handle this case? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Rave coefficient
A while back, Sylvain Gelly posted this code:
ChooseMove(node, board) {
bias = 0.015 // I put a random number here, to be tuned
b = bias * bias / 0.25
best_value = -1
best_move = PASSMOVE
for (move in board.allmoves) {
c = node.child(move).counts
w = node.child(move).wins
rc = node.rave_counts[move]
rw = node.rave_wins[move]
coefficient = 1 - rc / (rc + c + rc * c * b)
value = w / c * coef + rw / rc * (1 - coef) // please here take
care of
the c==0 and rc == 0 cases
if (value best_value) {
best_value = value
best_move = move
}
}
return best_move
}
From this, it appears that each node knows about its own counts and
wins, as well as the rave counts and wins of its children.
I understand (correct me if I'm wrong!) that the value line is a
weighted sum of the win rate among actual moves and the win rate among
RAVE moves.
My question is: what is the meaning of this line?
coefficient = 1 - rc / (rc + c + rc * c * b)
Why this formula?
Thanks for any help you can offer,
Peter Drake
http://www.lclark.edu/~drake/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] ADMIN TEST MSG - PLEASE DON'T RESPOND
___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo and passing
On http://www.lri.fr/~gelly/MoGo_Download.htmhttp://www.lri.fr/%7Egelly/MoGo_Download.htm, under the FAQ section, I found the bullet point: MoGo continues playing after the game is over?: MoGo never consider a pass unless you pass first. If you think the game is over, simply pass. Is this still true? If so, how does MoGo deal with situations where the best move is to pass (e.g. seki). When passing is necessary, mogo passes. So this sentence is not exactly true; mogo can pass first in extremal cases (very rare cases, against humans). Best regards, Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Complicated seki with Ko
Is it possible to explicitly use a monospace font? I can't read your board positions. I haven't heard of any handling of seki in playouts except for Remi's CrazyStone. I don't think he's ever given specifics on how he did it. Maybe he'll respond to your e-mail? Sent from my iPhone On Jun 26, 2009, at 1:37 PM, Brian Sheppard sheppar...@aol.com wrote: Here is a position that exposed some bugs in Pebbles. Maybe it will help you. 1 2 3 4 5 6 7 8 9 A - O - O X - - X - B - X O - O X - O O C - O O - O - X O - D X X X O O O O O O E - O X X X O X O O F - - O X O X X X X G - - X X O O X X - H - O X O - O O X X J - O X O O - X - X X to play. X is already doomed in this position. The bottom O group is in a seki with the X group at right. O cannot play J6 self-atari. X cannot fill in J8 and then play J6, and after X J6, O captures and X cannot recapture. So it will be dual life. Because the top of the board is O's, O have more than half the board, even without komi. The playouts have to handle certain issues well in order to find that. The first point is to filter out plays that make self-atari on large groups. This will cause the rest of the board to fill up until only the seki remains. The the playout will be in a position like the following: 1 2 3 4 5 6 7 8 9 A - O - O O - O O - B O - O - O O - O O C - O O - O - O O - D X X X O O O O O O E - X X X X O X O O F X X - X O X X X X G X - X X O O X X - H X X X O - O O X X J X - X O O - X - X X to play. Pebbles does not detect superko in playouts, so this position will loop forever with J6/J8/J7/pass. In Pebbles, infinite games were scored as draws. I changed that to give the win to O on the basis of its preponderance of material. (No doubt that will bite me at some point.) Even if we detect the superko repetition, it seems to me that we are only getting the right answer by accident. For instance, if X plays J6 then after J8/J7 there is no move for X, so X has self-ataried himself. Another possibility if to see that X's J6 is atari and also self- atari, so X can look for the approach move. In this case X would play J8 instead of J6 which avoids the ko. Then the seki is obvious. How do other programs handle this case? ___ 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] MoGo and passing
Hi, Olivier answered for the new version. On the downloadable version, I don't remember exactly (almost 2 years back now...), but I think Mogo will still pass if all the other moves are clearly loosing. So it should understand somehow Seki situations. If that is correct, the sentence is not completely accurate. It should more be: MoGo never consider a pass unless you pass first or all other moves are obviously loosing the game. Sylvain On Wed, Jun 24, 2009 at 10:11 PM, Seth Pellegrinose...@lclark.edu wrote: Hello all, On http://www.lri.fr/~gelly/MoGo_Download.htm , under the FAQ section, I found the bullet point: MoGo continues playing after the game is over?: MoGo never consider a pass unless you pass first. If you think the game is over, simply pass. Is this still true? If so, how does MoGo deal with situations where the best move is to pass (e.g. seki). Thanks, Seth Pellegrino ___ 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] Complicated seki with Ko
Jason, Gmail has an option show in fixed width font that is perfect for these situations. Álvaro. On Tue, Jun 30, 2009 at 1:25 PM, Jason Housejason.james.ho...@gmail.com wrote: Is it possible to explicitly use a monospace font? I can't read your board positions. I haven't heard of any handling of seki in playouts except for Remi's CrazyStone. I don't think he's ever given specifics on how he did it. Maybe he'll respond to your e-mail? Sent from my iPhone On Jun 26, 2009, at 1:37 PM, Brian Sheppard sheppar...@aol.com wrote: Here is a position that exposed some bugs in Pebbles. Maybe it will help you. 1 2 3 4 5 6 7 8 9 A - O - O X - - X - B - X O - O X - O O C - O O - O - X O - D X X X O O O O O O E - O X X X O X O O F - - O X O X X X X G - - X X O O X X - H - O X O - O O X X J - O X O O - X - X X to play. X is already doomed in this position. The bottom O group is in a seki with the X group at right. O cannot play J6 self-atari. X cannot fill in J8 and then play J6, and after X J6, O captures and X cannot recapture. So it will be dual life. Because the top of the board is O's, O have more than half the board, even without komi. The playouts have to handle certain issues well in order to find that. The first point is to filter out plays that make self-atari on large groups. This will cause the rest of the board to fill up until only the seki remains. The the playout will be in a position like the following: 1 2 3 4 5 6 7 8 9 A - O - O O - O O - B O - O - O O - O O C - O O - O - O O - D X X X O O O O O O E - X X X X O X O O F X X - X O X X X X G X - X X O O X X - H X X X O - O O X X J X - X O O - X - X X to play. Pebbles does not detect superko in playouts, so this position will loop forever with J6/J8/J7/pass. In Pebbles, infinite games were scored as draws. I changed that to give the win to O on the basis of its preponderance of material. (No doubt that will bite me at some point.) Even if we detect the superko repetition, it seems to me that we are only getting the right answer by accident. For instance, if X plays J6 then after J8/J7 there is no move for X, so X has self-ataried himself. Another possibility if to see that X's J6 is atari and also self-atari, so X can look for the approach move. In this case X would play J8 instead of J6 which avoids the ko. Then the seki is obvious. How do other programs handle this case? ___ 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] Passing and RAVE/AMAF
Yup, I can verify that my half-baked plan didn't work. If you use most wins to choose moves during playouts, once you have a win, you will never change your mind, because each playout will either increment that move (and maybe some others) or increment nothing (because it's a losing playout). So: Pebbles only for actual moves, not playout moves. On Jun 24, 2009, at 6:56 PM, Brian Sheppard wrote: The Pebbles rule (I should have published something better than this first, so that 'Pebbles Rule' could refer to something really cool) concerns solely the question of which move to select when your search is over. The conventional choice is to play the move that has the most *trials*, and Pebbles version is to play the move that has the most *wins*. Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo and passing
Obviously I should read better the emails before answering. Olivier rightly answered for all versions. Sorry, Sylvain On Tue, Jun 30, 2009 at 7:59 PM, Sylvain Gellysylvain.ge...@m4x.org wrote: Hi, Olivier answered for the new version. On the downloadable version, I don't remember exactly (almost 2 years back now...), but I think Mogo will still pass if all the other moves are clearly loosing. So it should understand somehow Seki situations. If that is correct, the sentence is not completely accurate. It should more be: MoGo never consider a pass unless you pass first or all other moves are obviously loosing the game. Sylvain On Wed, Jun 24, 2009 at 10:11 PM, Seth Pellegrinose...@lclark.edu wrote: Hello all, On http://www.lri.fr/~gelly/MoGo_Download.htm , under the FAQ section, I found the bullet point: MoGo continues playing after the game is over?: MoGo never consider a pass unless you pass first. If you think the game is over, simply pass. Is this still true? If so, how does MoGo deal with situations where the best move is to pass (e.g. seki). Thanks, Seth Pellegrino ___ 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] Complicated seki with Ko
zen builds sekis, and occasionally wins games that way. s. On Tue, Jun 30, 2009 at 1:25 PM, Jason Housejason.james.ho...@gmail.com wrote: Is it possible to explicitly use a monospace font? I can't read your board positions. I haven't heard of any handling of seki in playouts except for Remi's CrazyStone. I don't think he's ever given specifics on how he did it. Maybe he'll respond to your e-mail? Sent from my iPhone On Jun 26, 2009, at 1:37 PM, Brian Sheppard sheppar...@aol.com wrote: Here is a position that exposed some bugs in Pebbles. Maybe it will help you. 1 2 3 4 5 6 7 8 9 A - O - O X - - X - B - X O - O X - O O C - O O - O - X O - D X X X O O O O O O E - O X X X O X O O F - - O X O X X X X G - - X X O O X X - H - O X O - O O X X J - O X O O - X - X X to play. X is already doomed in this position. The bottom O group is in a seki with the X group at right. O cannot play J6 self-atari. X cannot fill in J8 and then play J6, and after X J6, O captures and X cannot recapture. So it will be dual life. Because the top of the board is O's, O have more than half the board, even without komi. The playouts have to handle certain issues well in order to find that. The first point is to filter out plays that make self-atari on large groups. This will cause the rest of the board to fill up until only the seki remains. The the playout will be in a position like the following: 1 2 3 4 5 6 7 8 9 A - O - O O - O O - B O - O - O O - O O C - O O - O - O O - D X X X O O O O O O E - X X X X O X O O F X X - X O X X X X G X - X X O O X X - H X X X O - O O X X J X - X O O - X - X X to play. Pebbles does not detect superko in playouts, so this position will loop forever with J6/J8/J7/pass. In Pebbles, infinite games were scored as draws. I changed that to give the win to O on the basis of its preponderance of material. (No doubt that will bite me at some point.) Even if we detect the superko repetition, it seems to me that we are only getting the right answer by accident. For instance, if X plays J6 then after J8/J7 there is no move for X, so X has self-ataried himself. Another possibility if to see that X's J6 is atari and also self-atari, so X can look for the approach move. In this case X would play J8 instead of J6 which avoids the ko. Then the seki is obvious. How do other programs handle this case? ___ 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] Rave coefficient
On Tue, Jun 30, 2009 at 12:47 AM, Peter Drakedr...@lclark.edu wrote:
A while back, Sylvain Gelly posted this code:
ChooseMove(node, board) {
bias = 0.015 // I put a random number here, to be tuned
b = bias * bias / 0.25
best_value = -1
best_move = PASSMOVE
for (move in board.allmoves) {
c = node.child(move).counts
w = node.child(move).wins
rc = node.rave_counts[move]
rw = node.rave_wins[move]
coefficient = 1 - rc / (rc + c + rc * c * b)
value = w / c * coef + rw / rc * (1 - coef) // please here take care of
the c==0 and rc == 0 cases
if (value best_value) {
best_value = value
best_move = move
}
}
return best_move
}
From this, it appears that each node knows about its own counts and wins, as
well as the rave counts and wins of its children.
I understand (correct me if I'm wrong!) that the value line is a weighted
sum of the win rate among actual moves and the win rate among RAVE moves.
My question is: what is the meaning of this line?
coefficient = 1 - rc / (rc + c + rc * c * b)
Why this formula?
You can look at a thread on this list
http://computer-go.org/pipermail/computer-go/2008-February/014095.html
and better the attachment explaining the formula.
http://computer-go.org/pipermail/computer-go/attachments/20080208/6519e9c5/rave.pdf
Hoping it helps,
Sylvain
Thanks for any help you can offer,
Peter Drake
http://www.lclark.edu/~drake/
___
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] Complicated seki with Ko
It might, but the iPhone mail viewer does not. Sent from my iPhone On Jun 30, 2009, at 2:00 PM, Álvaro Begué alvaro.be...@gmail.com wrote: Jason, Gmail has an option show in fixed width font that is perfect for these situations. Álvaro. On Tue, Jun 30, 2009 at 1:25 PM, Jason Housejason.james.ho...@gmail.com wrote: Is it possible to explicitly use a monospace font? I can't read your board positions. I haven't heard of any handling of seki in playouts except for Remi's CrazyStone. I don't think he's ever given specifics on how he did it. Maybe he'll respond to your e-mail? Sent from my iPhone On Jun 26, 2009, at 1:37 PM, Brian Sheppard sheppar...@aol.com wrote: Here is a position that exposed some bugs in Pebbles. Maybe it will help you. 1 2 3 4 5 6 7 8 9 A - O - O X - - X - B - X O - O X - O O C - O O - O - X O - D X X X O O O O O O E - O X X X O X O O F - - O X O X X X X G - - X X O O X X - H - O X O - O O X X J - O X O O - X - X X to play. X is already doomed in this position. The bottom O group is in a seki with the X group at right. O cannot play J6 self-atari. X cannot fill in J8 and then play J6, and after X J6, O captures and X cannot recapture. So it will be dual life. Because the top of the board is O's, O have more than half the board, even without komi. The playouts have to handle certain issues well in order to find that. The first point is to filter out plays that make self-atari on large groups. This will cause the rest of the board to fill up until only the seki remains. The the playout will be in a position like the following: 1 2 3 4 5 6 7 8 9 A - O - O O - O O - B O - O - O O - O O C - O O - O - O O - D X X X O O O O O O E - X X X X O X O O F X X - X O X X X X G X - X X O O X X - H X X X O - O O X X J X - X O O - X - X X to play. Pebbles does not detect superko in playouts, so this position will loop forever with J6/J8/J7/pass. In Pebbles, infinite games were scored as draws. I changed that to give the win to O on the basis of its preponderance of material. (No doubt that will bite me at some point.) Even if we detect the superko repetition, it seems to me that we are only getting the right answer by accident. For instance, if X plays J6 then after J8/J7 there is no move for X, so X has self-ataried himself. Another possibility if to see that X's J6 is atari and also self- atari, so X can look for the approach move. In this case X would play J8 instead of J6 which avoids the ko. Then the seki is obvious. How do other programs handle this case? ___ 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] lists working again
Hi, The archives kept updating but there was no out-going mail. veg ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Complicated seki with Ko
Not sure this helps, but... I found send-two receive-one, as in your example, to be the most common non-simple ko cycle in my program. The program was heavy, so forbidding send two added little to the total cost. Specifically, the rule forbade playing on an isolated empty intersection that neighbored a lone friendly stone that had started with two liberties. With light playouts, your mileage will probably vary. The reason I bothered with the prohibition is that I didn't properly handle graph-history interaction. Forbidding send-two greatly reduced GHI problems (simple ko was handled by counting the ko ban point, if any, as part of the position). In my program, not only did send-two receive-one outnumber all other long cycles combined four to one, but it happened that even when the longer cycles did occur, they rarely led to erroneous output, which was not the case for send-two receive-one. Double ko and triple ko seem more prominent in real games because they affect best play lines. Unbalanced ko cycles are usually very stupid plays for one side or the other, so people don't think about them very much. For a program dumb enough to be trapped by it, send-two receive-one can be important. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] self-play inflation
Wow, this is much more than I would have expected. I guess that settles it then, we cannot use gnugo as our anchor - it underates other programs :-) - Don On Thu, Jun 25, 2009 at 7:35 AM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote: I tested slef-play, and vs GNU Go by my program Aya. 9x9 result is from 1000 games. 19x19 result is from 349 - 550 games. If GNU Go is anchor in 19x19, my 2 playout version will get +195 elo. If Aya is anchor, it will get +488 elo. The difference is not small. 9x9 Aya self-play (against 360 playout/move) result winning rate, games 0.500 360 playout 0.714 1000 720 playout +159 elo 0.865 1000 1440 playout +323 elo 9x9 Aya vs GNU Go 3.7.10 result 0.488 1000 360 playout 0.633 1000 720 playout +104 elo 0.753 1000 1440 playout +203 elo 19x19 Aya self-play (against 5000 playout/move) result 0.500 --- 5000 playout 0.807 369 1 playout +249 elo 0.943 509 2 playout +488 elo 19x19 Aya vs GNU Go 3.7.10 0.538 401 5000 playout 0.676 550 1 playout +101 elo 0.782 349 2 playout +195 elo Regards, Hiroshi Yamashita ___ 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] Scoring - step function or sigmoid function?
It seems to be surprisingly difficult to outperform the step function when it comes to mc scoring. I know that many surprises await the mc adventurer, but completely discarding the final margin of victory just can't be optimal. ... an mc program, holding on to a half point victory in the endgame, is a thing of beauty and terror. But in the opening, where the scoring leaves are 300 moves away from the root, surely a putative half point win doesn't translate to a significant advantage, where as a 100 point win would. I had a breakthrough in my understanding of why it is surprisingly difficult to outperform the step function when analyzing some 9x9 games with Mogo and ManyFaces. Let's see if I can extract that insight into words... I observed that in many situations I could map the winning percentage to the final score. E.g. 50-55%: 0.5pt 55-60%: 1.5pt 60-65%: 2.5pt etc. It wasn't as clear cut as that. In fact what I was actually noticing was if I made a 1pt error the winning percentage for the opponent often jumped by, say, 5%. Thinking about why... In a given board position moves can be grouped into sets: the set of correct moves, the set of 1pt mistakes, 2pt mistakes, etc. Let's assume each side has roughly the same number of moves each in each of these groupings. If black is winning by 0.5pt with perfect play, then mistakes by each side balance out and we get a winning percentage of just over 50%. If he is winning by 1.5pt then he has breathing space and can make an extra mistake. Or in other words, at a certain move he can play any of the moves in the correct moves set, or any of the moves in the 1pt mistakes set, and still win. So he wins more of the playouts. Say 55%. If he is winning by 2.5pts then he can make one 2pt mistakes or two 1pt mistakes (more than the opponent) and still win, so he wins more playouts, 60% perhaps. And so on. My conclusion was that the winning percentage is more than just an estimate of how likely the player is to win. It is in fact a crude estimator of the final score. Going back to your original comment, when choosing between move A that leads to a 0.5pt win, and move B that leads to a 100pt win, you should be seeing move B has a higher winning percentage. Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/gobet/ (Shodan Go Bet - who will win?) http://dcook.org/mlsn/ (Multilingual open source 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/
