Re: [computer-go] MC heuristics not working
On Sat, Mar 17, 2007 at 02:12:21PM -0700, Christoph Birk wrote: > > On Sat, 17 Mar 2007, Chris Fant wrote: > >What does that have to do with it? My engine does not play > >multi-stone suicides, it only allows them in the playouts. As a > >result, it plays stronger. This is desirable, no? > > I doubt that it plays stronger against a reasonable opponent. > How could that be? One plausible explanation is that the playouts are played against a stupid random opponent. One that does not even try to capture stones, etc. So allowing also the own random moves to work towards getting the capturable stones captured, makes them look more weak, and thus gives a bit better overall idea of the situation. The pure random playouts have other strange features too, like often playing self-atari, because it might just be that the player got a second move in the neighbourhood before the opponent happens to capture the stone. That's why UCT or some other search is needed. In spite of it weaknesses, it ia amazing how well MC ends up playing! - Heikki -- Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re:[computer-go] MoGo
Quoting Don Dailey <[EMAIL PROTECTED]>: Do you think any version of gnugo is suitable as an anchor? My problem with Gnugo is that it might be too deterministic. It is in general easier to overfit the parameters to gnugo than an MC-program. But perhaps the gnugo team could make a version that at least in the opening plays as random as possible? It does not matter if it becomes a little weaker as long as it become unpredictable in the opening. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re:[computer-go] MoGo
Hello Don, Nick, Magnus, I here answer the 3 previous emails. 2007/3/18, Don Dailey <[EMAIL PROTECTED]>: Another possible candidate is Mogo, running at 3K play-outs, like the version running on CGOS right now. I thought about that, the good thing is the resources taken (between 0.6 and 0.3 s per move), the problem is this limited version MoGo seems to be too much "intransitive". Do you think any version of gnugo is suitable as an anchor? I think gnugo is a very good anchor and very difficult to overfit. It is good that ggexp is always playing. Last version of gnugo would also be good. As Magnus said, gnugo is maybe too deterministic, but this is only an issue if someone try to "cheat" by creating an winning opening against gnugo (I managed to find an opening which makes 100% against gnugo). I don't believe it is a practical issue then. On Sat, 2007-03-17 at 18:45 -0500, Nick Apperson wrote: > one concern i have is that within a family of programs (such as MC) > the estimated skill differences are overestimated. I would really > like to see an anchor that uses a different technique. I'm not > offering a solution. Thoughts? One idea is to measure this phenomenon to see how much we should be concerned by it. You are right. And the results you have so far in addition with the results in cgos can assess if it is wrong or right. I agree it is bad to have only MC programs running on cgos, but do we have a program > 2000 ELO which is not MC? Maybe a "solution" would be to take gnugo for example, and give it an advantage to make it at 2000 ELO (handicap or komi). This would however don't measure the level of a program against a strong one, but the ability of a program to catch up on a lost game. There is also the perspective of the 13x13 and 19x19 servers where (1) gnugo will be much stronger, (2) we can have easily handicaps. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re:[computer-go] MoGo
I'm not so sure we need to have a really strong Anchor. The Anchor's role is to prevent rating drift over the long term.It I turned CGOS lose without any anchor, it could inflate or deflate over time and that was the only reason I wanted to have an anchor. However, it makes sense for an Anchor to be close to the median strength of the players, otherwise it becomes like an Anchor attached to a long rubber band. It still anchors but there is too much wandering around. So I suggest that an upgrade is good, but it doesn't have to be top strength. I just did a quck estimate of the average strength of all the recent rated players and the average is close to 1600 if you throw out the negative rated players. This also coresponds roughly to the median player. I would still prefer favoring an Anchor that is more representative of stronger players as opposed to the simple heuristic players - so that pushes it up a bit more. When AnchorMan started out it was well above the median, now it's abot 100 ELO below give or take. A 1600 would be a big improvement and put it solidly into the median, but I think we want a couple of hundred above that to represent future improvements and build an Anchor around the stronger half. I think we need anything from 1800-2000 and this might be a version of gnugo with an enhanced highly varied opening book system. There are many versions of gnugo floating around. Which one is ggexp? Is is a version about to be released, part of the development cycle of gnugo? Or is there is a stronger version available? I could also put together a fixed version of Lazarus. Not the 2100 strength version but a version playing at a fixed level that would play the same strength on any computer. I could not run it on the server and I could not run it all the time from my home, but me might let 2 or 3 people run clones as Anchors.It would probably play about 1900 strength. In fact I could start preparing and testing a version that will hit this target strength. - Don On Sun, 2007-03-18 at 13:09 +0100, Sylvain Gelly wrote: > Hello Don, Nick, Magnus, > > I here answer the 3 previous emails. > > > 2007/3/18, Don Dailey <[EMAIL PROTECTED]>: > > Another possible candidate is Mogo, running at 3K play-outs, like the > > version running on CGOS right now. > > I thought about that, the good thing is the resources taken (between > 0.6 and 0.3 s per move), the problem is this limited version MoGo > seems to be too much "intransitive". > > > Do you think any version of gnugo is suitable as an anchor? > I think gnugo is a very good anchor and very difficult to overfit. It > is good that ggexp is always playing. Last version of gnugo would also > be good. As Magnus said, gnugo is maybe too deterministic, but this is > only an issue if someone try to "cheat" by creating an winning opening > against gnugo (I managed to find an opening which makes 100% against > gnugo). I don't believe it is a practical issue then. > > > On Sat, 2007-03-17 at 18:45 -0500, Nick Apperson wrote: > > > one concern i have is that within a family of programs (such as MC) > > > the estimated skill differences are overestimated. I would really > > > like to see an anchor that uses a different technique. I'm not > > > offering a solution. Thoughts? > > > > One idea is to measure this phenomenon to see how much we should > > be concerned by it. > You are right. And the results you have so far in addition with the > results in cgos can assess if it is wrong or right. > I agree it is bad to have only MC programs running on cgos, but do we > have a program > 2000 ELO which is not MC? Maybe a "solution" would be > to take gnugo for example, and give it an advantage to make it at 2000 > ELO (handicap or komi). This would however don't measure the level of > a program against a strong one, but the ability of a program to catch > up on a lost game. > > There is also the perspective of the 13x13 and 19x19 servers where (1) > gnugo will be much stronger, (2) we can have easily handicaps. > > Sylvain > ___ > 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: Re:[computer-go] MoGo
On Sun, Mar 18, 2007 at 01:09:27PM +0100, Sylvain Gelly wrote: > There is also the perspective of the 13x13 and 19x19 servers where (1) > gnugo will be much stronger, (2) we can have easily handicaps. Where are those? Are they used the same way as cgos? I would like to see what my MC does on a larger board. - Heikki -- Heikki Levanto "In Murphy We Turst" heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re:[computer-go] MoGo
Hello Heikki, 2007/3/18, Heikki Levanto <[EMAIL PROTECTED]>: On Sun, Mar 18, 2007 at 01:09:27PM +0100, Sylvain Gelly wrote: > There is also the perspective of the 13x13 and 19x19 servers where (1) > gnugo will be much stronger, (2) we can have easily handicaps. Where are those? Are they used the same way as cgos? I would like to see what my MC does on a larger board. I was talking about the future, as some already talked about some newer cgos server in 13x13 and/or 19x19 board sizes. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re:[computer-go] MoGo
2007/3/18, Don Dailey <[EMAIL PROTECTED]>: I'm not so sure we need to have a really strong Anchor. The Anchor's role is to prevent rating drift over the long term. You are right about this Anchor's role. However, to be able to accurately rate players, there is a need of opponents not too far from their strength. Of course there are already quite a lot of players on cgos, but they are not always connected, it is why I suggested the add of an strong "anchor" (maybe here the name is badly chosen), always connected. I could also put together a fixed version of Lazarus. Not the 2100 strength version but a version playing at a fixed level that would play the same strength on any computer. I could not run it on the server and I could not run it all the time from my home, but me might let 2 or 3 people run clones as Anchors. I think it would not too difficult to find volunteers to run it. For the next few months, I am sure I can find some computer with some CPU time for that. Sylvain - Don On Sun, 2007-03-18 at 13:09 +0100, Sylvain Gelly wrote: > Hello Don, Nick, Magnus, > > I here answer the 3 previous emails. > > > 2007/3/18, Don Dailey <[EMAIL PROTECTED]>: > > Another possible candidate is Mogo, running at 3K play-outs, like the > > version running on CGOS right now. > > I thought about that, the good thing is the resources taken (between > 0.6 and 0.3 s per move), the problem is this limited version MoGo > seems to be too much "intransitive". > > > Do you think any version of gnugo is suitable as an anchor? > I think gnugo is a very good anchor and very difficult to overfit. It > is good that ggexp is always playing. Last version of gnugo would also > be good. As Magnus said, gnugo is maybe too deterministic, but this is > only an issue if someone try to "cheat" by creating an winning opening > against gnugo (I managed to find an opening which makes 100% against > gnugo). I don't believe it is a practical issue then. > > > On Sat, 2007-03-17 at 18:45 -0500, Nick Apperson wrote: > > > one concern i have is that within a family of programs (such as MC) > > > the estimated skill differences are overestimated. I would really > > > like to see an anchor that uses a different technique. I'm not > > > offering a solution. Thoughts? > > > > One idea is to measure this phenomenon to see how much we should > > be concerned by it. > You are right. And the results you have so far in addition with the > results in cgos can assess if it is wrong or right. > I agree it is bad to have only MC programs running on cgos, but do we > have a program > 2000 ELO which is not MC? Maybe a "solution" would be > to take gnugo for example, and give it an advantage to make it at 2000 > ELO (handicap or komi). This would however don't measure the level of > a program against a strong one, but the ability of a program to catch > up on a lost game. > > There is also the perspective of the 13x13 and 19x19 servers where (1) > gnugo will be much stronger, (2) we can have easily handicaps. > > Sylvain > ___ > 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] UCT and optimization
UCT, alpha-beta, Monte-Carlo, and many others (not related to game playing) are all methods of optimization. In college we all did it countless times to find the maximum or minimum of a function. It's the simplest form of optimization. In an optimization two things are usually required: the accuracy and the efficiency in time and resources. To address the efficiency problem one thing can be used. That is an early indication which direction the optimization should go. Most analytical methods use the first and the second order derivatives as indicators. In UCT the values of the top level nodes are used as indicators. Then there is another problem in an optimization. It's the local maximum or minimum which may not be the overall optimum value. Many methods implemented ways to get out of local maxima or minima. When come to the real world problems, another problem appears. It's the noise in the measured data. This problem can more or less be treated with the same method of treating local maxima or minima. In the real world there are other optimization problems. The function one seek to optimize could be a random function with a known or unknown probability distribution. It's the extreme case of the noise problem mentioned earlier, except that the probability distribution may be different. It can also be treated as an extreme case oflocal maxima or minina. In UCT the term exploitation vs exploration (EvE) is just refering to the method of treating this (though extreme here) local maxima or minima. It does this by discounting the values obtained by examine its child nodes. Thus, UCT not only does exploitation and exploration, it also does probability distribution analysis of the values. The main method used is the averaging. From this understanding one improvement of the UCT applied to Go can immediately be made. That is the values of the higher level nodes should be averaged more and less for deep level nodes. Or the values of deeper level nodes should be weighed more in the averaging. This is because the MC evaluation becomes more and more accurate in deeper levels. Is this effect already included in UCT? Probably not. Because UCT is derived for the 'Bandit problem'. In the 'bandit problem' the value of the reward has the same distribution at any level of nodes. However, I have not go through the mathematics of UCT in detail. This effect could be already included even though 'Bandit problem' doesn't require it. Daniel Liu AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo
There is the possibility of more than one anchor. -Original Message- From: [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Sun, 18 Mar 2007 7:42 AM Subject: Re: Re:[computer-go] MoGo I'm not so sure we need to have a really strong Anchor. The Anchor's role is to prevent rating drift over the long term.It I turned CGOS lose without any anchor, it could inflate or deflate over time and that was the only reason I wanted to have an anchor. However, it makes sense for an Anchor to be close to the median strength of the players, otherwise it becomes like an Anchor attached to a long rubber band. It still anchors but there is too much wandering around. So I suggest that an upgrade is good, but it doesn't have to be top strength. I just did a quck estimate of the average strength of all the recent rated players and the average is close to 1600 if you throw out the negative rated players. This also coresponds roughly to the median player. I would still prefer favoring an Anchor that is more representative of stronger players as opposed to the simple heuristic players - so that pushes it up a bit more. When AnchorMan started out it was well above the median, now it's abot 100 ELO below give or take. A 1600 would be a big improvement and put it solidly into the median, but I think we want a couple of hundred above that to represent future improvements and build an Anchor around the stronger half. I think we need anything from 1800-2000 and this might be a version of gnugo with an enhanced highly varied opening book system. There are many versions of gnugo floating around. Which one is ggexp? Is is a version about to be released, part of the development cycle of gnugo? Or is there is a stronger version available? I could also put together a fixed version of Lazarus. Not the 2100 strength version but a version playing at a fixed level that would play the same strength on any computer. I could not run it on the server and I could not run it all the time from my home, but me might let 2 or 3 people run clones as Anchors.It would probably play about 1900 strength. In fact I could start preparing and testing a version that will hit this target strength. - Don On Sun, 2007-03-18 at 13:09 +0100, Sylvain Gelly wrote: > Hello Don, Nick, Magnus, > > I here answer the 3 previous emails. > > > 2007/3/18, Don Dailey <[EMAIL PROTECTED]>: > > Another possible candidate is Mogo, running at 3K play-outs, like the > > version running on CGOS right now. > > I thought about that, the good thing is the resources taken (between > 0.6 and 0.3 s per move), the problem is this limited version MoGo > seems to be too much "intransitive". > > > Do you think any version of gnugo is suitable as an anchor? > I think gnugo is a very good anchor and very difficult to overfit. It > is good that ggexp is always playing. Last version of gnugo would also > be good. As Magnus said, gnugo is maybe too deterministic, but this is > only an issue if someone try to "cheat" by creating an winning opening > against gnugo (I managed to find an opening which makes 100% against > gnugo). I don't believe it is a practical issue then. > > > On Sat, 2007-03-17 at 18:45 -0500, Nick Apperson wrote: > > > one concern i have is that within a family of programs (such as MC) > > > the estimated skill differences are overestimated. I would really > > > like to see an anchor that uses a different technique. I'm not > > > offering a solution. Thoughts? > > > > One idea is to measure this phenomenon to see how much we should > > be concerned by it. > You are right. And the results you have so far in addition with the > results in cgos can assess if it is wrong or right. > I agree it is bad to have only MC programs running on cgos, but do we > have a program > 2000 ELO which is not MC? Maybe a "solution" would be > to take gnugo for example, and give it an advantage to make it at 2000 > ELO (handicap or komi). This would however don't measure the level of > a program against a strong one, but the ability of a program to catch > up on a lost game. > > There is also the perspective of the 13x13 and 19x19 servers where (1) > gnugo will be much stronger, (2) we can have easily handicaps. > > Sylvain > ___ > 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/ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC heuristics not working
Just curious: in the playout, what happens when you allow it to play a multi-stone suicide? Does the group die, or do the stones remain on the board with no liberties? What happens to the final score? Group dies. I don't know what you mean about final score. It's Chinese scoring. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo
On Sun, 2007-03-18 at 10:48 -0400, [EMAIL PROTECTED] wrote: > There is the possibility of more than one anchor. At the moment, CGOS doesn't support more than 1 anchor player, but that is easily solved. However, I am in the testing stage of a new CGOS server. It does support as many anchors as you want. It comes with a number of improvements that I think many of the programmers will appreciate - mainly in terms of better feedback about what is going on. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re:[computer-go] MoGo
Hi Sylvain, I think what you are looking isn't a strong Anchor player, but strong players who are always available. However, I do want to upgrade the Anchor player too, perhaps putting up 2 Anchors. I will prepare a version of Lazarus - it will take a few days. I'm not sure what my goal rating is - I want it to play as strong as possible but still capable of being set up to run on modest computing systems. So I will have to experiment. I think it will easily be at least 1800 - perhaps as strong as 1900. You will of course need opponents who are as strong as possible in order to get accurate ratings. Unfortunately, you seem to have a monopoly on the strong programs! I haven't seen anything yet get beyond 2100 or so except versions of Mogo - which go all the way to well over 2400 assuming the ratings are relatively accurate. However, I'm sure that strong programs will follow. Meanwhile, Lazarus will be on and off - I'll try to keep it mostly on. I think there are at least 2 or 3 other programs in the same range that are not playing. Perhaps they will come back, perhaps with improvements. I think some of these programs are stronger than Lazarus, it's just that they are running on less hardware. Lazarus is running on a core 2 duo 6700 and it benefits from thinking on the opponents time. Some of these other programs are running on much slower pentiums and still approaching similar levels (without pondering.) Yes, all that stuff helps. - Don On Sun, 2007-03-18 at 15:10 +0100, Sylvain Gelly wrote: > 2007/3/18, Don Dailey <[EMAIL PROTECTED]>: > > I'm not so sure we need to have a really strong Anchor. The Anchor's > > role is to prevent rating drift over the long term. > You are right about this Anchor's role. However, to be able to > accurately rate players, there is a need of opponents not too far from > their strength. Of course there are already quite a lot of players on > cgos, but they are not always connected, it is why I suggested the add > of an strong "anchor" (maybe here the name is badly chosen), always > connected. > > > > I could also put together a fixed version of Lazarus. Not the > > 2100 strength version but a version playing at a fixed level > > that would play the same strength on any computer. I could > > not run it on the server and I could not run it all the time > > from my home, but me might let 2 or 3 people run clones as > > Anchors. > > I think it would not too difficult to find volunteers to run it. For > the next few months, I am sure I can find some computer with some CPU > time for that. > > Sylvain > > > > > > - Don > > > > > > On Sun, 2007-03-18 at 13:09 +0100, Sylvain Gelly wrote: > > > Hello Don, Nick, Magnus, > > > > > > I here answer the 3 previous emails. > > > > > > > > > 2007/3/18, Don Dailey <[EMAIL PROTECTED]>: > > > > Another possible candidate is Mogo, running at 3K play-outs, like the > > > > version running on CGOS right now. > > > > > > I thought about that, the good thing is the resources taken (between > > > 0.6 and 0.3 s per move), the problem is this limited version MoGo > > > seems to be too much "intransitive". > > > > > > > Do you think any version of gnugo is suitable as an anchor? > > > I think gnugo is a very good anchor and very difficult to overfit. It > > > is good that ggexp is always playing. Last version of gnugo would also > > > be good. As Magnus said, gnugo is maybe too deterministic, but this is > > > only an issue if someone try to "cheat" by creating an winning opening > > > against gnugo (I managed to find an opening which makes 100% against > > > gnugo). I don't believe it is a practical issue then. > > > > > > > On Sat, 2007-03-17 at 18:45 -0500, Nick Apperson wrote: > > > > > one concern i have is that within a family of programs (such as MC) > > > > > the estimated skill differences are overestimated. I would really > > > > > like to see an anchor that uses a different technique. I'm not > > > > > offering a solution. Thoughts? > > > > > > > > One idea is to measure this phenomenon to see how much we should > > > > be concerned by it. > > > You are right. And the results you have so far in addition with the > > > results in cgos can assess if it is wrong or right. > > > I agree it is bad to have only MC programs running on cgos, but do we > > > have a program > 2000 ELO which is not MC? Maybe a "solution" would be > > > to take gnugo for example, and give it an advantage to make it at 2000 > > > ELO (handicap or komi). This would however don't measure the level of > > > a program against a strong one, but the ability of a program to catch > > > up on a lost game. > > > > > > There is also the perspective of the 13x13 and 19x19 servers where (1) > > > gnugo will be much stronger, (2) we can have easily handicaps. > > > > > > Sylvain > > > ___ > > > computer-go mailing list > > > computer-go@computer-go.org > > > http://www.computer-go.org/mailman/listinfo/c
Re: Re:[computer-go] MoGo
Hi Don, I think what you are looking isn't a strong Anchor player, but strong players who are always available. In some sense you are right. In fact, I was not talking about anchor with fixed rating, but "floating" anchor, which would be a player with fixed strength, always connected. It is an anchor in the sense that the rating of other players then depend less on which programs are running. And this is quite important as the rating of a player depends mainly on the players which has a level close to it. So it is in this meaning I used the word "anchor", sorry for the confusion if any. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] libego questions on playout
Hi, On 3/17/07, Peter Christopher <[EMAIL PROTECTED]> wrote: Hi LL or any others who know, I've been playing with libego. Nice work, thanks for distributing it. I am working on understanding some of the details of uct.cpp, in particular how it does playouts in life-death and ko situations. I will try to add some helpful comments to the code once I have it figured out, so that others can more quickly understand it. You can also ask question (to me) and I will answer in form of comments. I found this a quite effective way of putting comments in proper places . ( to avoid: i++; // increases i :-] ) Perhaps you could help me out with a few basic questions. Does the board code (board.cpp) currently treat ko, suicide, multiple ko, etc, according to standard go rules or is there work remaining to be done for it to be precisely correct? simple ko is supported in board.cpp board.cpp::play_no_pass returns play_ko when illegal move (due to simple ko) was tried. Does the playout code (playout.cpp run() ) follow the board code exactly in examining the legality of "all possible moves"? Unfortunately, I do not understand Your question. simple_playout::run uses simple_playout::play_one which look for move that is not simple ko and not *single stone suicide* Best Regards, Thanks, Peter ___ 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] libego documentation
On 3/18/07, Peter Christopher <[EMAIL PROTECTED]> wrote: Hi, I plan to do some basic work documenting libego. My plan is as follows. 1) I will write what I have figured out and also the open issues on the sensei.xmp.net wiki. Anyone else obviously welcome to contribute, especially fix my errors and fill the gaps. 2) I will add some comments in the code & possibly modify the package to be more readily usable as a library as well as a hacking toybox. Any comments? Maybe it's a good idea to include Your documentation to libego. Sorry if my questions are somewhat newbie, I am still coming up to speed in this domain. Peter ps here again are several of my initial questions, please feel free to email me your response privately if you don't want to write publicly, and I will put it on the wiki. Perhaps you could help me out with a few basic questions. Does the board code (board.cpp) currently treat ko, suicide, multiple ko, etc, according to standard go rules or is there work remaining to be done for it to be precisely correct? I forgot to add that there is a stack_board, which take cares of superko. Does the playout code (playout.cpp run() ) follow the board code exactly in examining the legality of "all possible moves"? ___ 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: Re:[computer-go] MoGo
On Sun, 2007-03-18 at 19:09 +0100, Sylvain Gelly wrote: > Hi Don, > > > I think what you are looking isn't a strong Anchor player, but > > strong players who are always available. > > In some sense you are right. In fact, I was not talking about anchor > with fixed rating, but "floating" anchor, which would be a player with > fixed strength, always connected. It is an anchor in the sense that > the rating of other players then depend less on which programs are > running. > And this is quite important as the rating of a player depends mainly > on the players which has a level close to it. Yes, it's almost impossible to get an accurate rating if all your opponents are several hundred points stronger or weaker. That reminds me of another issue. The new CGOS will have a new pairing algorithm. Players will be selected who are close in strength and there will be less variety, but less mis-matched games. It's pretty much a waste of time to pair Mogo vs Random for instance and that won't happen on the new CGOS unless there just isn't enough players close to your strength. In fact, it will work more like a ladder system - but not quite as restrictive. The new pairing algorithm works like this: 1. A random value is added to each players rating for pairing. 2. Players to be scheduled are sorted according to this pseudo rating. 3. Pairings are matched pairwise in order, from top to bottom. The amount of randomness added to each players rating (for pairing purposes only) is determined dynamically. It will be a value that still guarantees a chance to get paired with at least 3 or 4 opponents on either side of your rank. Of course this algorithms also introduces a bias - you are more likely to get paired with a player next to you than with a player 2 or 3 ranks away.The gap may be greater for some players than others, as it is computed based on all available players at pairing time. But the bias is based on strength more than rank - if an opponent is only 1 rating point stronger, you are more likely to get paired against him than you are another opponent right next to you - but 150 ELO weaker. A minor enhancement is that colors against a specific opponent are no longer chosen randomly - they are equalized. So if you play white against Foo, the next time you will get black. Even if they get out of whack the server will work to correct this, but that should never happen unless the database is tampered with. Another feature is that if an opponent disconnects by accident (or on purpose), the game can continue by reconnecting. Of course the clock keeps running - there is no resuming of games the next day. The SGF files contain all the timing information for each move and the time each player takes for a given game will be reported on the web pages. The opponents name and rating will be reported to the client and passed on to the engine if it supports an extended GTP command to do this.(Any ideas on what to call this command?) Some of these features will require client support and may not immediately appear until I enhance the client versions. For instance the client can be made to produce SGF files so they do not need to be downloaded - the information needed is available to construct a clone of the SGF record stored on CGOS. - Don > So it is in this meaning I used the word "anchor", sorry for the > confusion if any. > > Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] computer go documentation issues
Taking a look at computer go documentation, I see that there are (at least) three pages that exist in wiki format for top level "computer go" wiki pages- wikipedia.org - computer go sensei - computer go sensei - computer go programming It seems obvious that these are redundant. It seems prudent to combine them in one location. Which location? I am thinking that wikipedia would be the main page. The other two (sensei pages) would temporarily just get a big heading on top saying "THIS PAGE IS FOR HISTORICAL REFERENCE ONLY. OFFICIAL WIKI COMPUTER GO PAGE IS AT WIKIPEDIA.ORG. FOLLOW THIS LINK." On a related note, should *any* computer go documentation be at sensei? Maybe everything other than the main page? Or maybe everything in computer go should be moved to wikipedia? At the very least, we ought to make prominent notes on the wikipedia and sensei pages of the existence of the other. Any opinions? Peter ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] computer go documentation issues
I fully agree with your plan. Merging it all onto wikipedia seems like a good plan to me. Certainly forwarding the others is a must too. On 3/18/07, Peter Christopher <[EMAIL PROTECTED]> wrote: Taking a look at computer go documentation, I see that there are (at least) three pages that exist in wiki format for top level "computer go" wiki pages- wikipedia.org - computer go sensei - computer go sensei - computer go programming It seems obvious that these are redundant. It seems prudent to combine them in one location. Which location? I am thinking that wikipedia would be the main page. The other two (sensei pages) would temporarily just get a big heading on top saying "THIS PAGE IS FOR HISTORICAL REFERENCE ONLY. OFFICIAL WIKI COMPUTER GO PAGE IS AT WIKIPEDIA.ORG. FOLLOW THIS LINK." On a related note, should *any* computer go documentation be at sensei? Maybe everything other than the main page? Or maybe everything in computer go should be moved to wikipedia? At the very least, we ought to make prominent notes on the wikipedia and sensei pages of the existence of the other. Any opinions? Peter ___ 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] average length of 9x9 MC playout
I've seen the number 107.3... reported earlier for the average length, without the 2 final passes. Is this allowing multi stone suicides or not? And what's the outcome in the other case? Thanks! regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] computer go documentation issues
I think they serve different purposes. Wikipedia has its "no original research" policy meaning that theoretically everything in a Wikipedia article should be backed up by a citation. That's certainly not true now, but it should be a goal. So it seems like there will be lots of details (such as the change history of individual computer go programs) that don't belong at Wikipedia and would be more welcome at Sensei. - Brian On 3/18/07, Nick Apperson <[EMAIL PROTECTED]> wrote: I fully agree with your plan. Merging it all onto wikipedia seems like a good plan to me. Certainly forwarding the others is a must too. On 3/18/07, Peter Christopher <[EMAIL PROTECTED]> wrote: > Taking a look at computer go documentation, I see that there are (at > least) three pages that exist in wiki format for top level "computer go" > wiki pages- > > wikipedia.org - computer go > sensei - computer go > sensei - computer go programming > > It seems obvious that these are redundant. It seems prudent to combine > them in one location. Which location? I am thinking that wikipedia > would be the main page. The other two (sensei pages) would temporarily > just get a big heading on top saying "THIS PAGE IS FOR HISTORICAL > REFERENCE ONLY. OFFICIAL WIKI COMPUTER GO PAGE IS AT WIKIPEDIA.ORG. > FOLLOW THIS LINK." > > On a related note, should *any* computer go documentation be at sensei? > Maybe everything other than the main page? Or maybe everything in > computer go should be moved to wikipedia? > > At the very least, we ought to make prominent notes on the wikipedia and > sensei pages of the existence of the other. > > Any opinions? > > Peter > ___ > 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] average length of 9x9 MC playout
On Sun, 2007-03-18 at 22:33 -0400, John Tromp wrote: > I've seen the number 107.3... reported earlier > for the average length, without the 2 final passes. > Is this allowing multi stone suicides or not? > And what's the outcome in the other case? > Thanks! This does not allow multi-stone suicide. I don't know the number in the other case. I just checked Lazarus again and it's getting about 104.63 moves per random game from the opening.There are some minor implementation differences such as how suicide is handled, the exact eye rule used, etc. The heavy play-out version of Lazarus gets almost the same number, but it's consistently about 1/10 of move lower for some reason. Are you trying to make a Monte Carlo program? - Don > regards, > -John > ___ > 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] average length of 9x9 MC playout
heavy playouts should yeild a lower number of moves because moves are slightly more efficient bringing the end of the game sooner. I'm actually surprised it isn't a larger difference. On 3/18/07, Don Dailey <[EMAIL PROTECTED]> wrote: On Sun, 2007-03-18 at 22:33 -0400, John Tromp wrote: > I've seen the number 107.3... reported earlier > for the average length, without the 2 final passes. > Is this allowing multi stone suicides or not? > And what's the outcome in the other case? > Thanks! This does not allow multi-stone suicide. I don't know the number in the other case. I just checked Lazarus again and it's getting about 104.63 moves per random game from the opening.There are some minor implementation differences such as how suicide is handled, the exact eye rule used, etc. The heavy play-out version of Lazarus gets almost the same number, but it's consistently about 1/10 of move lower for some reason. Are you trying to make a Monte Carlo program? - Don > regards, > -John > ___ > 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] average length of 9x9 MC playout
On Sun, 2007-03-18 at 22:34 -0500, Nick Apperson wrote: > heavy playouts should yeild a lower number of moves because moves are > slightly more efficient bringing the end of the game sooner. I'm > actually surprised it isn't a larger difference. I never tested it until now - but I expected it to drop at least a couple of moves. I did not expect a huge drop because the game is played to the bitter end in either case. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] average length of 9x9 MC playout
John, Did that 107.3 number come from me? I seem to remember that I used to get that - if I'm remembering correctly. But I remember making a little change, that addressed what appeared to be a minor implementation bug. One of the speed enhancements is to "put away" moves you already tried which occupy points on the board. When a capture is made I would bring these back into play. But the bug was that I was putting away the moves that filled the 1 point eyes, even though they might be legal on the next move or later. However they would all come back to life when a capture was made. I don't think this bug had a huge affect on the quality of the play. But apparently, it did add about 3 moves to the length of the play-outs. So I think the more correct number is what I just reported on the previous email, very close to about 104.63. I am now curious about what others are getting. - Don On Sun, 2007-03-18 at 22:33 -0400, John Tromp wrote: > I've seen the number 107.3... reported earlier > for the average length, without the 2 final passes. > Is this allowing multi stone suicides or not? > And what's the outcome in the other case? > Thanks! > > > regards, > -John > ___ > 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/
