Re: [computer-go] pseudo eye variations for playouts
It is important to know about potential blind spots introduced by pseudo-eye
variations, or any
other rules.
Borrowing from Eric S Raymond, the more eyes inspecting the ideas, the
shallower the bugs.
Thanks! Here goes another attempt, this time trying to construct an
example where pseudo-eyes prevent a necessary fill-in ('a' is J15,
'b' is L17, 'c' is F12, and 'd' is K16).
Claus
(
;
FF[4]
GM[1]
SZ[19]
AP[Jago:Version 5.0]
AB[hd][id][je][jf][if][hf][he][jb][ld][le][lf][lg][kh][jh][ih][hh][gh]
[fg][ff][fe][fd][fc][gb][hb][ib][kb][lc][fb][lh]
AW[gc][hc][ic][jc][kd][ke][kf][jg][ig][hg][gf][ge][gd][kg][gg][ga][ha]
[ia][ja][ka][la][lb][mc][mb][md][me][mf][mg][ki][ji][ii][hi][gi][fi]
[eh][eg][ef][ee][ed][ec][eb][ea][fa][mh][li]
C[black to move.
Gobble, Olga, and Oleg agree:
'a' is an eye, cannot be filled.
Black 'b' or 'c' would put black's outer group in atari, accelerating its
death.
A random opponent might fail to respond to black 'b' with white 'c',
permitting black 'd' to kill white, and black to live. If there are no
remaining outside moves, or the opponent is not quite random (heavy
playouts with capture preference, say), black 'b' or 'c' amounts to suicide.
The only other local move is black 'd', which allows and forces white 'a'
to live, killing black.
If filling 'a' was not ruled out, playing there would kill white, allowing
black to live.
The pseudo-eye definitions blind black to the winning shaped sacrifice
of what can never become part of a two-eye group, turning a likely live
(after selecting the best first move) black group into a likely dead one
(with survival depending on context and opponent weakness).]
LB[ie:a][kc:b][fh:c][jd:d]
GN[playout-eyes2]
)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote: I have a rough idea of what that might be. And I suspect that keeping this de facto standard implicit has been hiding some actual differences in what different people think that standard is. Some of my questions arise from trying to pin down where and why different authors have different ideas of what the standard is. If there has been some explicit standardisation since those papers were published, I'd be interested in a pointer to that standard and its rationale. I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] pseudo eye variations for playouts
There is a de facto standard light playout policy (algorithm). I have a rough idea of what that might be. And I suspect that keeping this de facto standard implicit has been hiding some actual differences in what different people think that standard is. Some of my questions arise from trying to pin down where and why different authors have different ideas of what the standard is. If there has been some explicit standardisation since those papers were published, I'd be interested in a pointer to that standard and its rationale. If you want to adhere to this standard, then by definition, there are correct and incorrect ways to do so. If you just want to design a better playout policy, naturally anything is fair game. Neither, actually!-) If there was a single standard, then implementing that first would be useful before starting on variations. But only if said standard was arrived at by community optimization, not by committee or by failure to examine hypotheses for their validity (it works in most cases is no proof that it works, let alone that there isn't a more complete way to do the same thing). The more everyone always implements the same thing because everyone does it that way, the less that way is guaranteed to be tested for flaws (local extrema, exploration vs exploitation?-). Mostly, I like to understand what I'm doing and why, instead of just implementing and optimizing what has been handed down. So I take the slow, scenic route to writing my own implementation, using coding only to test and improve my understanding of what I've read while enjoying the pleasure of finding things out. Usually, that either leads to requests for clarification/suggestions for possible improvements or to being more comfortable with the standard (because I've tried to shoot it down and failed - coming to grips with it;-). After all that initial learning has settled down, and the basis is solid, there'll come a time for testing new ideas. But how are you going to measure whether it's really better? By trying to understand the issues in enough depth that I can design concrete experiments that will test concrete hypotheses?-) And if the theory is good enough, experiments might not even be necessary in all cases (or rather, a single proof might cover an infinity of experiments), though I expect experiments to be helpful in most cases. My advice is to keep to this standard for a little while longer, write the rest of your engine, run it on CGOS where you can compare it directly with programs like myCtestxxx (maintained for that purpose by generous individuals) and verify that the other parts work. Then start improving the playout policy. I fully expect to try my code against others at some point (though I don't have a permanent internet connection atm, so couldn't let anything run via a server for long). But that isn't urgent yet. What is urgent is not to build in limiting assumptions (in either code or understanding) that will be difficult to back out of once there is more code. Don't get me wrong: I have switched from pure hypotheses to working on code, though only on the side, and I think the various community resources (servers, wikis, software, list archives, papers, bibliographies, ..) are great. A FAQ with urls, archive pointers, search keywords, and glossary would help newcomers (with pointers to it in the list headers and mailman listinfo page). If the list had a wiki, newcomers like myself could simply add what they find to a FAQ page on that wiki before we forget how difficult it was to find in the first place. Claus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Go/Games with modified scores
During the last few days I have been meditating a lot about the questiion whether taking into account the margin of win into MCTS (UCT) may help or hurt. I do not have a go program by my own, so for the moment I have to believe what programmers are saying, namely that MCTS with margin of win as a criterion gives worse performance in play against other computer programs. So, a negative answer... but there may be other points of view from which this phenomenon is not bad but helpful. To give an example: I am active in the scene of computer-aided game inventing. When a human designer of board games has invented a new game he typically needs many rounds of human test players who find strengths and weaknesses of the game. As it is really a hard job to find enough test players our idea is to let the early phases of test play be done by computer in autoplay mode. (The list of basic criteria for good games include appropriate game length, balance of chances, low drawing rates.) When you now think of a game where the overall goal is to win and to avoid losing, but where also a margin of win/loss can be counted at the end (Go belongs to this class) you may pit two versions of your MCTS algorithm against each other: * MCTS(WinLoss), playing only for a win, independently of the margin * MCTS (margin), playing for win/loss, but also considering the margin. with the philosophy: The game is interesting, when MCTS(WinLoss) performs better than MCTS(margin), and boring when it is the other way. Ingo. PS: Here is an early report on computer-aided game inventing. http://www.minet.uni-jena.de/preprints/althoefer_03/CAGI.pdf -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] OCTOBER KGS Computer Go tournament: small boards, slow
Reminder - it's tomorrow. The October 2008 KGS computer Go tournament will be on Sunday October 12th, in the Asian evening, European morning and American night, starting at 08:00 UTC (GMT) and ending soon after 12:00 UTC (GMT). The Formal division will be a 6-round Swiss with 13x13 boards and 28 minutes main time. The Open division will be a 9-round Swiss with 9x9 boards and 18 minutes each main time. Both will use Chinese rules with 7.5 points komi. There are details at http://www.gokgs.com/tournInfo.jsp?id=422 for the Formal division, and at http://www.gokgs.com/tournInfo.jsp?id=424 for the Open. For the first time, this event will not use sudden death. It will use a very fast Canadian Overtime, of 25 moves in 20 minutes, for each division. It was my intention to use 20 moves in 20 seconds, but there appears to be a bug in the KGS tournament configuration software, such that when I specify 20 stones in 20 seconds, the server takes it to mean 25 stones in 20 seconds. So the settings for this event are: Formal division 28 minutes + 25 stones/20 seconds Open division 18 minutes + 25 stones/20 seconds Registration is now open. To enter, please read and follow, as usual, the instructions at http://www.weddslist.com/kgs/how/index.html. The rules are given at http://www.weddslist.com/kgs/rules.html. Please send your registration email (with the words KGS Tournament Registration in the title) to me at maproom at gmail dot com (converted to a valid address in the obvious way). 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] pseudo eye variations for playouts
Don's draft standard reminded me of the corner cases. So here's
an even simpler example, this time trying to show that dead invading
stones can poison playout analysis depending on which definition of
pseudo-eyes is used ('a' is A1, 'b' is C1).
That makes three attempted examples so far (are the examples
valid for what they are trying to show?), trying to show:
- the standard Gobble pseudo-eye can both allow real eyes
to be filled and prevent sacrifices involving filling false eyes
(in all cases so far, resulting in own groups counting as more
likely dead, and opponent groups counting as more likely live;
but since the playouts are symmetric, that implies miscounting
both ways)
- the local pattern approach of Gobble can be poisoned by
dead opponent neighbours
I understand that some engines use pseudo-liberties, or may
not have connection information easily accessible all the time,
but for those who do maintain proper liberty counts: are there
any examples where Olga-style pseudo-eyes are not preferable
to (at least as good as) Gobble-style ones?
Claus
(
;
FF[4]
GM[1]
SZ[19]
AP[Jago:Version 5.0]
AB[ar][bs][bq][cq][dr][ds][dq][aq]
AW[br][cr][ap][bp][cp][dp][eq][er][es]
LB[as:a][cs:b]
C[The black group is unconditionally alive.
Gobble: 'a' is not an eye, group is unsettled (50% chance: black 'a' dies,
black 'b' lives).
Olga: 'a' is an eye, black 'b' the only possible local move: group is alive.
Oleg: 'a' is not an eye, group is unsettled (50% chance: black 'a' dies, black
'b' lives).]
GN[playout-eyes3]
)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] pseudo eye variations for playouts
Thanks! Here goes another attempt, this time trying to construct an
example where pseudo-eyes prevent a necessary fill-in ('a' is J15,
'b' is L17, 'c' is F12, and 'd' is K16).
..
GN[playout-eyes2]
Sorry about that one! I must have been thinking of some form of
Carpenter's square or square nine in the corner, but quite apart
from somehow managing to set up the whole thing away from the
corner, that shape is far too complex for such a simple argument
to succeed.
Please don't waste your time on playout-eyes2,-(
Claus
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] simple MC reference bot and specification
If you don't have sueperko, I think you need a maximum moves stopping criteria too. -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Saturday, October 11, 2008 6:11 AM To: computer-go Subject: [computer-go] simple MC reference bot and specification On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote: I have a rough idea of what that might be. And I suspect that keeping this de facto standard implicit has been hiding some actual differences in what different people think that standard is. Some of my questions arise from trying to pin down where and why different authors have different ideas of what the standard is. If there has been some explicit standardisation since those papers were published, I'd be interested in a pointer to that standard and its rationale. I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] pseudo eye variations for playouts
Yes, it's understood that the eye rule most of us use is not perfect and
we have identified bad cases before on this list.
My analogy is that you wouldn't put expensive leather seats in a cheap
economy car. A simple eye rule is more than sufficient for random
play-outs. A more sophisticated rule is interesting to consider of
course, but I'm pretty sure it would not be a measurable improvement to
a random playout based program.In fact I think even the really good
programs like mogo use this same simple eye rule.
I thought the Gobble eye rule was the one we are using now? Or maybe
I'm thinking of a different program?
If you are interested in corner cases I think some previous postings
here are worthy of consideration.Did you also check Sensei's page?
- Don
On Sat, 2008-10-11 at 15:01 +0100, Claus Reinke wrote:
Don's draft standard reminded me of the corner cases. So here's
an even simpler example, this time trying to show that dead invading
stones can poison playout analysis depending on which definition of
pseudo-eyes is used ('a' is A1, 'b' is C1).
That makes three attempted examples so far (are the examples
valid for what they are trying to show?), trying to show:
- the standard Gobble pseudo-eye can both allow real eyes
to be filled and prevent sacrifices involving filling false eyes
(in all cases so far, resulting in own groups counting as more
likely dead, and opponent groups counting as more likely live;
but since the playouts are symmetric, that implies miscounting
both ways)
- the local pattern approach of Gobble can be poisoned by
dead opponent neighbours
I understand that some engines use pseudo-liberties, or may
not have connection information easily accessible all the time,
but for those who do maintain proper liberty counts: are there
any examples where Olga-style pseudo-eyes are not preferable
to (at least as good as) Gobble-style ones?
Claus
(
;
FF[4]
GM[1]
SZ[19]
AP[Jago:Version 5.0]
AB[ar][bs][bq][cq][dr][ds][dq][aq]
AW[br][cr][ap][bp][cp][dp][eq][er][es]
LB[as:a][cs:b]
C[The black group is unconditionally alive.
Gobble: 'a' is not an eye, group is unsettled (50% chance: black 'a' dies,
black 'b' lives).
Olga: 'a' is an eye, black 'b' the only possible local move: group is alive.
Oleg: 'a' is not an eye, group is unsettled (50% chance: black 'a' dies,
black 'b' lives).]
GN[playout-eyes3]
)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
signature.asc
Description: This is a digitally signed message part
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
I found one specified issue that must be handled and requires an additional specification. What to do to limit the length of the playout games? As was discussed in the last couple of days or so there are possible cases with multiple ko threats. Please not that the solution I am about to propose doesn't pretend to be a perfect solution since this is just a benchmark (like th eye rule, it isn't perfect) - but I think it does solve the problem. My idea is this: Allow up to N consecutive 1 point captures and then automatically terminate the game.So here is rule 13 in my list: 13. the play-outs terminate after the fifth consecutive 1 stone capture. If someone has a rationale for using a different number let's consider it. I picked 5 for no particular reason. And yes, I know that this might terminate games too early, but the only problem I want to solve is to prevent infinite games. There is of course an argument for using a much bigger number such as 10 or more - 5 single stone captures doesn't prove any kind of ko situation. But I prefer a very simple termination rule that is trivial to implement to something anal and complicated. I don't want to scare anybody away from building this benchmark. Would that guarantee no infinite games?Is there a reason to use a higher number than 5? Should we have an even simpler termination rule such as no playout shall last more than BOARDSIZE * BOARDSIZE * 3 moves? In addition I think it's good to require that integer komi be allowed. - Don On Sat, 2008-10-11 at 09:11 -0400, Don Dailey wrote: I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, Oct 11, 2008 at 8:11 AM, Don Dailey [EMAIL PROTECTED] wrote: I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. Wouldn't it make more sense to run an equal number of playouts for each root move? 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. I think maybe this should be something deterministic. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. This is too vague IMO--I think specifying the RNG would be better. I like Marsaglia's--that's what I use now. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. That's fine for this spec, but I don't do this and don't plan on it. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. positional superko (as opposed to situational superko). - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Sat, 11 Oct 2008 9:11 am Subject: [computer-go] simple MC reference bot and specification On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote: I have a rough idea of what that might be. And I suspect that keeping this de facto standard implicit has been hiding some actual differences in what different people think that standard is. Some of my questions arise from trying to pin down where and why different authors have different ideas of what the standard is. If there has been some explicit standardisation since those papers were published, I'd be interested in a pointer to that standard and its rationale. I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Oct 11, 2008, at 2:40 PM, [EMAIL PROTECTED] wrote: 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. positional superko (as opposed to situational superko). Whatever is used by the rules... I know CGOS and KGS Chinesee use positional super ko. I don't know which rule sets would use situational. Situational makes more sense to me. - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Sat, 11 Oct 2008 9:11 am Subject: [computer-go] simple MC reference bot and specification On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote: I have a rough idea of what that might be. And I suspect that keeping this de facto standard implicit has been hiding some actual differences in what different people think that standard is. Some of my questions arise from trying to pin down where and why different authors have different ideas of what the standard is. If there has been some explicit standardisation since those papers were published, I'd be interested in a pointer to that standard and its rationale. I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ McCain or Obama? Stay updated on coverage of the Presidential race while you browse - Download Now! ___ 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] simple MC reference bot and specification
On Sat, 2008-10-11 at 13:34 -0500, Zach Wegner wrote: Wouldn't it make more sense to run an equal number of playouts for each root move? No, because with AMAF you will get different game counts ANYWAY. And also I believe most programs are viewing the level in playouts as a fixed number of play-outs, not a fixed number of play-outs per root move choice and I would want to conform to what most people are doing. However I'm not opposed to doing it that way, especially if that's what most people are already doing anyway. But I'm just trying to nail down what most people are already doing so that only minor changes would be necessary to anyone wanting to implement this. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 13:34 -0500, Zach Wegner wrote: 7. In the case of moves with even scores a random selection is made. I think maybe this should be something deterministic. That of course is clearly a possibility. However I'm trying to approach this with a certain consistent methodology which is to specify the BEHAVIOR, not the implementation. I want complete freedom in how you implement the specified behavior. Also, if you chose a different generator, it would not be possible to prove it if it were a good one. Not unless we also got heavy handed about how it's initialized, and how you select moves with a random distribution.In short, I fear that we would be asking too much to build a bunch of clones that are completely deterministic. If you look at pseudo random number generators you will see there is this same implicit methodology, though not stated. The behavior specified is to appear random and test are designed to see how well this behavior is simulated.In some sense, people consider the best random number generators to be the ones that fool the Diehard tests. They fool these diehard tests into thinking they are really random. I want this to work that way. We will build tests and I don't care if you can find a way to fool the tests. However the tester will be designed to be difficult to fool and it will not present you with predictable positions. I don't care if you don't follow the spec 100% if you can fool the tests. If you can do this, you will probably have found something useful to all of us. This is not going to be a formal thing like the Computer Benchmarks Game is. We will just build a tester and publish the spec and you can do what you want with it. Maybe put entries on Sensei's page. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] 2nd GPW Cup Computer Go Tournament in Hakone, Japan
The 2nd GPW Cup Gomputer Go Tournament will be held as a night event of Game Programming Workshop 2008. GPW2008: http://sig-gi.c.u-tokyo.ac.jp/gpw/2008/ (in Japanese) #Those who can't read Japanese and have interests in paticipating GPW Cup Computer Go Tournament, please mail me. The 13th Game Programming Workshop will be held November 7 - 9 at Hakone Seminor House, Hakone, Japan. GPW Cup Computer Go Tournament will be held at the first and second nights, together with the other night events, such as GPW Cup Computer Shogi Tournament, using Chinese rules, round robin alternating black and white, 15 minutes SD, and 6.5 points komi. Participants have to prepare necessary equipments by themselves (no Internet connection is available at the Seminor House, no loan PCs and/or no agents are provided by the organizer). The programs should be original. Human players can participate as well. The rules of the tournament may be changed on particular conditions if necessary, ex., if there will be too many participants to keep the schedule. Hideki -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 13:34 -0500, Zach Wegner wrote: 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. That's fine for this spec, but I don't do this and don't plan on it. You don't have to do it, it's just a provision to allow your bot to play legal games. The tester probably won't require it since it will just be looking for statistics from specified (random) positions. A more comprehensive test is to play games with these reference bots and check to see if any are straying too far from 50% scores against the others.Your program could still participate, although it would probably lose slightly more than the others due to the occasionally superko loss. Hopefully, this comprehensive tester could identify just from the game statistics that something is wrong. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 14:40 -0400, [EMAIL PROTECTED] wrote: 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. positional superko (as opposed to situational superko). Thank you. I forgot to specify which. - Don - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Sat, 11 Oct 2008 9:11 am Subject: [computer-go] simple MC reference bot and specification On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote: I have a rough idea of what that might be. And I suspect that keeping this de facto standard implicit has been hiding some actual differences in what different people think that standard is. Some of my questions arise from trying to pin down where and why different authors have different ideas of what the standard is. If there has been some explicit standardisation since those papers were published, I'd be interested in a pointer to that standard and its rationale. I'm going to publish a real simple java reference program and some docs to go with it and a program to test it for black box conformance. (Actually, it will test 2 or more and compare them.) I would like to get someone who writes better than I do to write up the standard in less casual language but it goes something like this: 1. A complete game playing program so it can also be tested in real games. 2. Play uniformly random moves except to 1 pt eyes and avoiding simple ko. When a move is otherwise not possible, pass. 3. Playout ends after 2 consecutive pass moves (1 for each side.) 4. 1 pt eye is an empty point surrounded by friendly stones for the side to move. Additionally, we have 2 cases. If the stone is NOT on any edge (where the corner is an edge) there must be no more than one diagonal enemy stone.If the point in question is on the edge, there must be NO diagonal enemy stones. 5. In the playouts, statistics are taken on moves played during the playouts. If the move is played FIRST (during the playout) by the side to move it is one data point and the win loss record is maintained. 6. The move with the highest statistical win rate is the one selected for move in the actual game. 7. In the case of moves with even scores a random selection is made. 8. Pass move are never selected as the final move to play unless no other non-eye filling move is possible. 9. Random number generator is unspecified - your program should simply pass the black box test and as a further optional test your program should score close to 50% against other properly implemented programs. 10. Suicide not allowed in the playouts or in games it plays. 11. When selecting moves to play in the actual game (not playouts) superko is checked and forbidden. 12. If a move has NO STATS taken (which is highly unlikely unless you do very few playouts) it is ignored for move selection. Did I miss anything? I would like to get feedback and agreement on this. Please note - a few GTP commands will be added in order to instrument any conforming programs. Haven't figured those out yet, but it will be designed so that it can report number of nodes, number of playouts, average score of playouts, etc. So the tester may set up some position and a ko, and ask for statistics based on the number of specified playouts. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ McCain or Obama? Stay updated on coverage of the Presidential race while you browse - Download Now! signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 14:48 -0400, Jason House wrote: Whatever is used by the rules... I know CGOS and KGS Chinesee use positional super ko. I don't know which rule sets would use situational. Situational makes more sense to me. I've always personally preferred situation super ko (probably because of my chess background) but Position Super Ko seems to be the more popular standard and CGOS uses it as well as KGS. What are most people using? - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] simple MC reference bot and specification
On point 13. 1 stone captures, may eventually be hard for some implementation. I think using game length as a criterion gives more freedom. Then you have to specify what to do with those pathological games anyway. Do you score them as they are, or do you drop them. I do count them. The rule for counting is probably quite standard too. I give a point for each stone present. Then for each empty stone, i give a point to the side who has all orthogonal control of it, if any. I usually implements super-ko checking very late, if i do at all. I often start by selecting either the first or the last best move, rather than picking one at random. Although picking at random makes me more comfortable somehow. It could be interesting to see how much difference it makes. Finally, about the size. Is it supposed to be 9x9 only ? 9x9 only gives more freedom to fine tune for this size. It may make the implementations less useful, if someone knows another sizes the light-policy could succeed on. (like maybe studying 7x7 and such ?) _ Email envoyé avec Windows Live Hotmail. Dites adieux aux spam et virus, passez à Hotmail ! C'est gratuit ! http://www.windowslive.fr/hotmail/default.asp___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 21:46 +0200, Denis fidaali wrote: On point 13. 1 stone captures, may eventually be hard for some implementation. I think using game length as a criterion gives more freedom. I definitely considered that. My own program returns the number of stones captured (and a list of those stones if I ask for it) and so it's easy for me, but wonder if there are programs where this would be difficult to detect? My arguments in favor of the rule is that it's not quite as artificial as setting some arbitrary limit and I think this would not unduly delay the terminations of games. With a limit of hundreds of moves, some games would go hundreds of moves beyond what is necessary. Are there any MC programs out that cannot detect whether they made a one stone capture and it would be unduly difficult to fix this? Then you have to specify what to do with those pathological games anyway. Do you score them as they are, or do you drop them. I do count them. You score them as is. You may not get the correct score, but after all these ARE random games and we expect this to be extremely rare. The rule for counting is probably quite standard too. I give a point for each stone present. Then for each empty stone, i give a point to the side who has all orthogonal control of it, if any. Yes. Tromp/Taylor which are Chinese rules. I usually implements super-ko checking very late, if i do at all. I often start by selecting either the first or the last best move, rather than picking one at random. Although picking at random makes me more comfortable somehow. It could be interesting to see how much difference it makes. Of course everyone is free to implement any variation they want, controlled by switches and such.The idea is to have an extremely reliable benchmark and this will also be very helpful for new developers as this also would serve as a good first program for new developers and they could have confidence that they got all the details right. Finally, about the size. Is it supposed to be 9x9 only ? It can be anything you want, but I suggest that you develop a program capable of playing on any board size. Having said that, you can get a little more speed if you code to just 1 specific board size. Lazarus compiles to any ODD board size but it's fixed at compile time and I have to recompile to get other board sizes. I doubt this optimization is worth very much and it's annoying that I have to fetch a different binary in order to play other board sizes. Also, I don't really keep up with how new processor families change the rules. I know that I USED to get a nice speedup several years ago by using as many constants as possible (as opposed to variables) but I have no idea whether (or how much) this is true today. 9x9 only gives more freedom to fine tune for this size. It may make the implementations less useful, if someone knows another sizes the light-policy could succeed on. (like maybe studying 7x7 and such ?) How do you define succeed?It works on all board sizes, it just works better on smaller boards. You could equally say it doesn't work on any board size since there are ways to build stronger programs. - Don _ Email envoyé avec Windows Live Hotmail. Dites adieux aux spam et virus, passez à Hotmail ! C'est gratuit ! http://www.windowslive.fr/hotmail/default.asp___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
Don Dailey wrote: Are there any MC programs out that cannot detect whether they made a one stone capture and it would be unduly difficult to fix this? They would have to detect that to detect simple Ko. Speaking of which, wouldn't it be better to limit consecutive Kos instead of limiting consecutive 1-stone captures? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 16:32 -0400, Michael Williams wrote: Don Dailey wrote: Are there any MC programs out that cannot detect whether they made a one stone capture and it would be unduly difficult to fix this? They would have to detect that to detect simple Ko. That's a good point. Speaking of which, wouldn't it be better to limit consecutive Kos instead of limiting consecutive 1-stone captures? Wouldn't this definitely slow down most if not all light implementations and require code changes to existing programs? My own programs do not really know that a ko exists until it decides to make that specific move. Then when it tries to play that move the make() routine discovers that it is was a ko and reject it, returning an illegal move value. To fix this I would have to test every move just to see if there is a ko situation (although there are no doubt some shortcuts.) So I don't think that is a practical rule although it is without doubt slightly superior. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
Don Dailey wrote: Speaking of which, wouldn't it be better to limit consecutive Kos instead of limiting consecutive 1-stone captures? Wouldn't this definitely slow down most if not all light implementations and require code changes to existing programs? My own programs do not really know that a ko exists until it decides to make that specific move. Then when it tries to play that move the make() routine discovers that it is was a ko and reject it, returning an illegal move value. To fix this I would have to test every move just to see if there is a ko situation (although there are no doubt some shortcuts.) I detect simple Ko at the time of the legal capture. I'm curious how you do it at the time of the illegal capture attempt. How do you tell a legal 1-stone capture from an illegal one? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 16:55 -0400, Don Dailey wrote: To fix this I would have to test every move just to see if there is a ko situation (although there are no doubt some shortcuts.) One shortcut is to simply not test for this until after you make a 1 stone capture, then test all possible moves for the previous position. But of course this greatly complicates most implementations I fear. An extension of this shortcut is to delay ALL testing until the number of 1 stone captures indicate that you need to test N previous positions for KO. This would not be easy for me unless I were to accept the slowdown of using my slow move maker in the playouts. My slow move maker maintains full state between moves. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
On Sat, 2008-10-11 at 17:01 -0400, Michael Williams wrote: Don Dailey wrote: Speaking of which, wouldn't it be better to limit consecutive Kos instead of limiting consecutive 1-stone captures? Wouldn't this definitely slow down most if not all light implementations and require code changes to existing programs? My own programs do not really know that a ko exists until it decides to make that specific move. Then when it tries to play that move the make() routine discovers that it is was a ko and reject it, returning an illegal move value. To fix this I would have to test every move just to see if there is a ko situation (although there are no doubt some shortcuts.) I detect simple Ko at the time of the legal capture. I'm curious how you do it at the time of the illegal capture attempt. How do you tell a legal 1-stone capture from an illegal one? An illegal one stone capture is a capture of the same stone that was just used to make a 1 stone capture itself. I think I got that right. Whenever there is a 1 stone capture I flag that and remember it's location (in the move list stack) but a one stone capture does not imply a KO and that takes time to test - so I don't test. So I don't know that a capture move is a KO and most of the time I don't need to know. The next player selects a random move, which MIGHT be a capture attempt which is illegal due to simple KO. If it is, only then do I know that the previous move was a KO. I'm slightly confused by the language ko what is a ko? To me a ko is illegal so it never happens but I suppose my definition is wrong and it's any board position where an illegal repetition is possible due to whatever ko rule is in effect. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go/Games with modified scores
Ingo Althöfer wrote: During the last few days I have been meditating a lot about the questiion whether taking into account the margin of win into MCTS (UCT) may help or hurt. I do not have a go program by my own, so for the moment I have to believe what programmers are saying, namely that MCTS with margin of win as a criterion gives worse performance in play against other computer programs. I think the computer go field has a lot of magical thinking like this. Where a couple of different teams try out an idea, no one can get it to work, and so everyone believes the idea is no good. The truth is we don't know. Most of computer go is very empirical and ad-hoc. We don't know why playing out a game randomly many times gives a good approximation of winning chance (I'm sure I could design games where this is not true). Using the margin and not just win/loss would intuitively seem to mean a higher margin of error in this estimate, so that a lot more play-outs are needed to take advantage of any added information. But that would really just be another guess. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] simple MC reference bot and specification
David Fotland suggested another rule, tell me what you think. His rule is to stop the game at or beyond move N*N*2 where N is the board size and score the board no matter what. But in the play-outs he first plays 1 move before making this test. If a game actually lasts that long, the play-outs are not worth much but the game is probably over anyway and the board gets scored as is. My own implementation depends on there being no eyes bigger than 1 point, because it's fast and easy to score a board that has only 1 point eyes. But a simple modification makes it work without any appreciable speed sacrifice: If a game ends beyond move N*N*2 then use the slow scoring routine that doesn't assume the board is complete. It should be very rare that this routine has to be used. - Don On Sat, 2008-10-11 at 16:15 -0400, Don Dailey wrote: On Sat, 2008-10-11 at 21:46 +0200, Denis fidaali wrote: On point 13. 1 stone captures, may eventually be hard for some implementation. I think using game length as a criterion gives more freedom. I definitely considered that. My own program returns the number of stones captured (and a list of those stones if I ask for it) and so it's easy for me, but wonder if there are programs where this would be difficult to detect? My arguments in favor of the rule is that it's not quite as artificial as setting some arbitrary limit and I think this would not unduly delay the terminations of games. With a limit of hundreds of moves, some games would go hundreds of moves beyond what is necessary. Are there any MC programs out that cannot detect whether they made a one stone capture and it would be unduly difficult to fix this? Then you have to specify what to do with those pathological games anyway. Do you score them as they are, or do you drop them. I do count them. You score them as is. You may not get the correct score, but after all these ARE random games and we expect this to be extremely rare. The rule for counting is probably quite standard too. I give a point for each stone present. Then for each empty stone, i give a point to the side who has all orthogonal control of it, if any. Yes. Tromp/Taylor which are Chinese rules. I usually implements super-ko checking very late, if i do at all. I often start by selecting either the first or the last best move, rather than picking one at random. Although picking at random makes me more comfortable somehow. It could be interesting to see how much difference it makes. Of course everyone is free to implement any variation they want, controlled by switches and such.The idea is to have an extremely reliable benchmark and this will also be very helpful for new developers as this also would serve as a good first program for new developers and they could have confidence that they got all the details right. Finally, about the size. Is it supposed to be 9x9 only ? It can be anything you want, but I suggest that you develop a program capable of playing on any board size. Having said that, you can get a little more speed if you code to just 1 specific board size. Lazarus compiles to any ODD board size but it's fixed at compile time and I have to recompile to get other board sizes. I doubt this optimization is worth very much and it's annoying that I have to fetch a different binary in order to play other board sizes. Also, I don't really keep up with how new processor families change the rules. I know that I USED to get a nice speedup several years ago by using as many constants as possible (as opposed to variables) but I have no idea whether (or how much) this is true today. 9x9 only gives more freedom to fine tune for this size. It may make the implementations less useful, if someone knows another sizes the light-policy could succeed on. (like maybe studying 7x7 and such ?) How do you define succeed?It works on all board sizes, it just works better on smaller boards. You could equally say it doesn't work on any board size since there are ways to build stronger programs. - Don _ Email envoyé avec Windows Live Hotmail. Dites adieux aux spam et virus, passez à Hotmail ! C'est gratuit ! http://www.windowslive.fr/hotmail/default.asp___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 2nd GPW Cup Computer Go Tournament in Hakone, Japan
Google translate does a pretty god job of translating these pages. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Hideki Kato Sent: Saturday, October 11, 2008 12:13 PM To: computer-go@computer-go.org Subject: [computer-go] 2nd GPW Cup Computer Go Tournament in Hakone, Japan The 2nd GPW Cup Gomputer Go Tournament will be held as a night event of Game Programming Workshop 2008. GPW2008: http://sig-gi.c.u-tokyo.ac.jp/gpw/2008/ (in Japanese) #Those who can't read Japanese and have interests in paticipating GPW Cup Computer Go Tournament, please mail me. The 13th Game Programming Workshop will be held November 7 - 9 at Hakone Seminor House, Hakone, Japan. GPW Cup Computer Go Tournament will be held at the first and second nights, together with the other night events, such as GPW Cup Computer Shogi Tournament, using Chinese rules, round robin alternating black and white, 15 minutes SD, and 6.5 points komi. Participants have to prepare necessary equipments by themselves (no Internet connection is available at the Seminor House, no loan PCs and/or no agents are provided by the organizer). The programs should be original. Human players can participate as well. The rules of the tournament may be changed on particular conditions if necessary, ex., if there will be too many participants to keep the schedule. Hideki -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go/Games with modified scores
On Sat, 2008-10-11 at 22:33 +0100, Raymond Wold wrote: Ingo Althöfer wrote: During the last few days I have been meditating a lot about the questiion whether taking into account the margin of win into MCTS (UCT) may help or hurt. You are not alone! I think most of us have looked into that. I do not have a go program by my own, so for the moment I have to believe what programmers are saying, namely that MCTS with margin of win as a criterion gives worse performance in play against other computer programs. It seems that way so far but you never know. I think the computer go field has a lot of magical thinking like this. Where a couple of different teams try out an idea, no one can get it to work, and so everyone believes the idea is no good. I couldn't say it better myself. In fact I have dropped my own ideas, only to make them work later. One can never be completely sure there is not a bug, or some implementation detail that seemed unimportant caused a problem. The truth is we don't know. Most of computer go is very empirical and ad-hoc. We don't know why playing out a game randomly many times gives a good approximation of winning chance (I'm sure I could design games where this is not true). Using the margin and not just win/loss would intuitively seem to mean a higher margin of error in this estimate, so that a lot more play-outs are needed to take advantage of any added information. But that would really just be another guess. Are you speculating that if enough play-outs are done, the idea might prove to be superior?I never actually considered that. So perhaps with 5000 playouts using the win/loss score wins, but at 50,000 using the margin might be better? This is easy to test with simple MC go programs.If I get a chance I will test it for you (since you do not have a program of your own) and report the results. I'm not holding my breath however ... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go/Games with modified scores
Don Dailey wrote: Are you speculating that if enough play-outs are done, the idea might prove to be superior?I never actually considered that. So perhaps with 5000 playouts using the win/loss score wins, but at 50,000 using the margin might be better? This is easy to test with simple MC go programs.If I get a chance I will test it for you (since you do not have a program of your own) and report the results. I'm not holding my breath however ... Indeed, that was my /guess/. And one aimed at rationalizing why this particular idea might somehow work. It might well be that something else is needed to utilize the score difference after a play-out, or it might be that it really is worthless... Without a much deeper understanding (in a mathematical sense, not a player-skill sense*) of go, I don't see how we can find out which ideas really can't work. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go/Games with modified scores
On Sat, 2008-10-11 at 23:49 +0100, Raymond Wold wrote: Don Dailey wrote: Are you speculating that if enough play-outs are done, the idea might prove to be superior?I never actually considered that. So perhaps with 5000 playouts using the win/loss score wins, but at 50,000 using the margin might be better? This is easy to test with simple MC go programs.If I get a chance I will test it for you (since you do not have a program of your own) and report the results. I'm not holding my breath however ... Indeed, that was my /guess/. And one aimed at rationalizing why this particular idea might somehow work. It might well be that something else is needed to utilize the score difference after a play-out, or it might be that it really is worthless... Without a much deeper understanding (in a mathematical sense, not a player-skill sense*) of go, I don't see how we can find out which ideas really can't work. I believe there have been many attempts to make this work. These attempts are based on the intuition that the margin approach should be better even though it is clearly inferior. So in my opinion they start with a wrong premise. And this wrong premise is combined with another wrong premise that the win/loss thing is inherently flawed, but works due to some fluke. So the idea is to somehow combine something that seems to work very well, with something clearly inferior and get something that works better than both! I'm guessing that most approaches based on combining the two scoring systems is like taking great wine and mixing it with cheap wine and hoping to come up with something superb. Also, one must consider if it's even possible to get much more out of the win/loss method anyway. How much more can you gain making it fight when it is dead lost or dead one?That is probably why it has been so difficult to improve, because you have so little to gain. To me it's now a question of finding a way to make it behave more like people do without weakening it too much.I don't have a lot of hope that you will improve it and even if you do, it will be a small improvement. But I think it's possible to improve the behavior we find so ugly without unduly weakening it. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Go/Games with modified scores
On 11-okt-08, at 20:32, Don Dailey wrote: I believe there have been many attempts to make this work. These attempts are based on the intuition that the margin approach should be better even though it is clearly inferior. So in my opinion they start with a wrong premise. And this wrong premise is combined with another wrong premise that the win/loss thing is inherently flawed, but works due to some fluke. I think this is rather a mischaracterization of why people look for this. I think people (me included) feel that replacing a whole swath of relevant information by a single number points to potentially some serious inefficiency and loss of information. The fact that nobody has found how to make use of the excess of information is no proof of course that it can't be done. I think it's a very valid question at the very least and a bit premature to call it a wrong premise. MCTS programs are still in their early days of development and it's quite possible some good improvements can be made by using more information than the simple win/loss ratio. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
