Re: [computer-go] New CGOS - need your thoughts.
I'm voting for 2 time settings: One normal and one fast (so maybe 5 min and 1 min on 9x9). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
From what I can see, there is resistance to this idea - so what I'm going to do is to provide venues which are standalone but makes it possible later to add a time control.In other words for now there will be only 1 time control per board size but the server will be flexible enough that other venues can be added if the server ever gets popular enough that we have 40 or 50 players always on line. But they will be separate venues scheduled independently. - Don On Tue, Jun 16, 2009 at 8:08 AM, Isaac Deutsch i...@gmx.ch wrote: I'm voting for 2 time settings: One normal and one fast (so maybe 5 min and 1 min on 9x9). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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] New CGOS - need your thoughts.
Maybe we could agree that 1 day out of 7 in a week would be played on 6 times faster time controls. The same bots, connections, logins, the same number of games per week. Different rating of course. This would be a problem only for hardcoded bots with no time control. The advantage would be that we would see how different algorithms (bots) scale. If the ratings would be very similar for most bots, it would mean that we can get faster testing of new ideas. We would know which ideas can be tested of fast time control. Lukasz 2009/6/16 Don Dailey dailey@gmail.com: From what I can see, there is resistance to this idea - so what I'm going to do is to provide venues which are standalone but makes it possible later to add a time control. In other words for now there will be only 1 time control per board size but the server will be flexible enough that other venues can be added if the server ever gets popular enough that we have 40 or 50 players always on line. But they will be separate venues scheduled independently. - Don On Tue, Jun 16, 2009 at 8:08 AM, Isaac Deutsch i...@gmx.ch wrote: I'm voting for 2 time settings: One normal and one fast (so maybe 5 min and 1 min on 9x9). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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] New CGOS - need your thoughts.
I vote for 2 venues, each optional. Separate rating pools is a must. Łukasz Lew wrote: Maybe we could agree that 1 day out of 7 in a week would be played on 6 times faster time controls. The same bots, connections, logins, the same number of games per week. Different rating of course. This would be a problem only for hardcoded bots with no time control. The advantage would be that we would see how different algorithms (bots) scale. If the ratings would be very similar for most bots, it would mean that we can get faster testing of new ideas. We would know which ideas can be tested of fast time control. Lukasz 2009/6/16 Don Dailey dailey@gmail.com: From what I can see, there is resistance to this idea - so what I'm going to do is to provide venues which are standalone but makes it possible later to add a time control.In other words for now there will be only 1 time control per board size but the server will be flexible enough that other venues can be added if the server ever gets popular enough that we have 40 or 50 players always on line. But they will be separate venues scheduled independently. - Don On Tue, Jun 16, 2009 at 8:08 AM, Isaac Deutsch i...@gmx.ch wrote: I'm voting for 2 time settings: One normal and one fast (so maybe 5 min and 1 min on 9x9). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
Whatever the eventual decision is - personally I would love a fast-play venue as an alternative, with separate rating - please don't worry too much about engines with fixed playouts, or engines that cannot handle certain time limits. The GTP client sitting between the engine and server will be able to protect the engine, by either keeping it out of games it cannot support or issuing it with reconfiguration commands. Christian Michael Williams wrote: I vote for 2 venues, each optional. Separate rating pools is a must. Łukasz Lew wrote: Maybe we could agree that 1 day out of 7 in a week would be played on 6 times faster time controls. The same bots, connections, logins, the same number of games per week. Different rating of course. This would be a problem only for hardcoded bots with no time control. The advantage would be that we would see how different algorithms (bots) scale. If the ratings would be very similar for most bots, it would mean that we can get faster testing of new ideas. We would know which ideas can be tested of fast time control. Lukasz 2009/6/16 Don Dailey dailey@gmail.com: From what I can see, there is resistance to this idea - so what I'm going to do is to provide venues which are standalone but makes it possible later to add a time control.In other words for now there will be only 1 time control per board size but the server will be flexible enough that other venues can be added if the server ever gets popular enough that we have 40 or 50 players always on line. But they will be separate venues scheduled independently. - Don On Tue, Jun 16, 2009 at 8:08 AM, Isaac Deutsch i...@gmx.ch wrote: I'm voting for 2 time settings: One normal and one fast (so maybe 5 min and 1 min on 9x9). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Christian Nentwich Director, Model Two Zero Ltd. +44-(0)7747-061302 http://www.modeltwozero.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
On Mon, 15 Jun 2009, Brian Sheppard wrote: Please don't do anything that decreases the frequency of games in order to accommodate programs that want to play on multiple venues. Keep venues strictly separate. Programs that want to play on multiple venues can just log in multiple times. I second that opinion. If there is a second venue, I'd prefer longer time controls. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
I agree with David. Have one time control per board size. I like the 5-minute controls for 9x9. You can take your program down for extensive offline testing and still get 100 games per day. That is far more data than you can analyze. Still, the speed is fast enough for ratings to stabilize in a day or two. The argument for longer time controls is that it encourages the development of new algorithms. New algorithms are usually slower. It might take 10 man hours to quickly code up a new idea. Sure we can optimize it to run 10 times quicker, but that takes another 90 man hours. We want to see how well an idea works before spending all that effort. If the same bot plays both 5 minute games and 20 minute games, and the server can show different ratings for each venue, it would show how well that program's algorithms scale. Darren P.S. I'm not competing any time soon, so this cannot really count as a vote for longer time controls. -- Darren Cook, Software Researcher/Developer http://dcook.org/gobet/ (Shodan Go Bet - who will win?) http://dcook.org/mlsn/ (Multilingual open source semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
On Mon, Jun 15, 2009 at 9:43 PM, Jason House jason.james.ho...@gmail.comwrote: Given all the negative reaction to nested time control, I have to say I like it. The pool won't be diluted as long as there's an obvious main venue. A good compromise might be to have only 2 venues, one such as David suggested and another one that is quite a bit faster. Another possibility is to make BOTH venues mandatory - but my fear is that some programs may not be able to play fast enough and would always time out.Or they may not implement a proper time control algorithm and thus would not be able to adapt to 2 different time controls without being reinitialized with different parameters. Sent from my iPhone On Jun 15, 2009, at 7:20 PM, Don Dailey dailey@gmail.com wrote: I've been working on the new server and I'm almost at the point where I can think about time controls - and since this is primarily for developers, I would like to get your thoughts. First, a brief explanation of how the time control works. When the client starts up it will inform the server of which venues it is willing to play in. It must choose an available boardsize and then any of N different time controls. Initially, N will probably be 2 or 3. For each board size, a time control is called a venue. Let's assume there are 3 venues for boardsize 9x9. The time control for each venue will be significantly different from the others. One will be very fast, one will be very slow and there will be one in between. Each time control will be in sync with the others and the process will be recursive. So the basic scheduling algorithm is to NOT start a new round for a given venue until any players who have registered to play in this venue and are currently playing in FASTER venues are available for scheduling. In addition to this, new rounds are not scheduled for any particular venue as long as the next slower venue is stalled waiting for these faster venues to complete. I hope this idea allows more choice and keeps players busy a greater percentage of the time by allowing them to fill dead space with fast games. Each bot can choose which venues to play in. If you only want to play fast games, then you can. Now the questions I pose to you are these: How many venues for each boardsize? (two, three, more?) What time controls should they be? It's almost certainly the case that certain combinations of time control venues will work together better than others. There will always be the issue of waiting for games to complete and in fact this may make the problem a bit worse for those programs that only want to play in the longest venue. I suggest that each venue is spaced at least a factor of 2 apart in time. For instance 1 minute, 2 minutes, 4 minutes, etc. My own suggestion for 9x9 is to have 3 venues of 1 minute, 5 minutes and 15 minutes per game per player. It's also not too late to change our minds and not have venues if we think the disadvantages outweigh the advantages. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
I'll express my opinion here, but keep in mind that my engine (cogito) has only played 44 games as of now on CGOS. I have a few problems with separate time controls. --It dilutes the rating pool. If there is only one time control, everyone can play everyone. If there are separate time controls, then there will probably be some players that only play in certain time controls. Thus the rating pools must be kept separate to not introduce bias. Separate rating pools reduce the amount of useful data available. --There are better ways to accomplish the same goals. As you suggested, you could simply wait until half of all players are idle, and then start another round. You could take this even further. I suppose in the current CGOS you have some measurement on whether two players would make an acceptable match in the next round? Whenever a player becomes idle, and there is at least one other player idle, try and match them if they are close enough. There wouldn't be any more rounds, but I think this would be a better solution. --It introduces complexity. Some players (like mine) don't have any time control code. Mine has to be recompiled to play at different numbers of playouts. This is because it's an ultra minimal engine, only 1937 characters of C at the moment (by IOCCC counting rules). It plays on CGOS using an adapter shell script. I'd rather not have to rewrite that! There are plenty of players that play at fixed playout counts. Zach ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
I'm for keeping the number of pools small, to keep their sizes large. Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS - need your thoughts.
On Mon, Jun 15, 2009 at 11:18 PM, Zach Wegner zweg...@gmail.com wrote: I'll express my opinion here, but keep in mind that my engine (cogito) has only played 44 games as of now on CGOS. I have a few problems with separate time controls. --It dilutes the rating pool. If there is only one time control, everyone can play everyone. If there are separate time controls, then there will probably be some players that only play in certain time controls. Thus the rating pools must be kept separate to not introduce bias. Separate rating pools reduce the amount of useful data available. This would not dilute anything if everyone played in all venues, it would only increase the total amount of data. Of course if players opt out of certain levels it would dilute it somewhat. Separate ratings is something I definitely planned on doing. --There are better ways to accomplish the same goals. As you suggested, you could simply wait until half of all players are idle, and then start another round. You could take this even further. I suppose in the current CGOS you have some measurement on whether two players would make an acceptable match in the next round? Whenever a player becomes idle, and there is at least one other player idle, try and match them if they are close enough. There wouldn't be any more rounds, but I think this would be a better solution. Actually an early version of CGOS did this and it does not work so well. What happens is that when the first match is over, BOTH of those players are now available and they play each other again and this never ends. So I had this hack to prevent consecutive matches against the same players. It helped a little but the real problem is that you need a lot of players available to prevent lots of mismatches while still maintaining diversity. CGOS wants to give you many different players to play, while not giving you too many ridiculous mismatches. --It introduces complexity. Some players (like mine) don't have any time control code. Mine has to be recompiled to play at different numbers of playouts. This is because it's an ultra minimal engine, only 1937 characters of C at the moment (by IOCCC counting rules). It plays on CGOS using an adapter shell script. I'd rather not have to rewrite that! There are plenty of players that play at fixed playout counts. Yes, I agree complexity is an issue. I can handle this in the server but I want it to be easy to make a simple bot that works. - Don Zach ___ 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] New CGOS - need your thoughts.
If more than one venue is mandatory I probably won't be able to join, since I want to spend my limited programming time making the engine stronger, not programming multiple time controls. Please allow me to play with just a singe time limit without changing my cgos interface code. David From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Don Dailey Sent: Monday, June 15, 2009 7:02 PM To: computer-go Subject: Re: [computer-go] New CGOS - need your thoughts. On Mon, Jun 15, 2009 at 9:43 PM, Jason House jason.james.ho...@gmail.com wrote: Given all the negative reaction to nested time control, I have to say I like it. The pool won't be diluted as long as there's an obvious main venue. A good compromise might be to have only 2 venues, one such as David suggested and another one that is quite a bit faster. Another possibility is to make BOTH venues mandatory - but my fear is that some programs may not be able to play fast enough and would always time out. Or they may not implement a proper time control algorithm and thus would not be able to adapt to 2 different time controls without being reinitialized with different parameters. Sent from my iPhone On Jun 15, 2009, at 7:20 PM, Don Dailey dailey@gmail.com wrote: I've been working on the new server and I'm almost at the point where I can think about time controls - and since this is primarily for developers, I would like to get your thoughts. First, a brief explanation of how the time control works. When the client starts up it will inform the server of which venues it is willing to play in. It must choose an available boardsize and then any of N different time controls. Initially, N will probably be 2 or 3. For each board size, a time control is called a venue. Let's assume there are 3 venues for boardsize 9x9. The time control for each venue will be significantly different from the others. One will be very fast, one will be very slow and there will be one in between. Each time control will be in sync with the others and the process will be recursive. So the basic scheduling algorithm is to NOT start a new round for a given venue until any players who have registered to play in this venue and are currently playing in FASTER venues are available for scheduling. In addition to this, new rounds are not scheduled for any particular venue as long as the next slower venue is stalled waiting for these faster venues to complete. I hope this idea allows more choice and keeps players busy a greater percentage of the time by allowing them to fill dead space with fast games. Each bot can choose which venues to play in. If you only want to play fast games, then you can. Now the questions I pose to you are these: How many venues for each boardsize? (two, three, more?) What time controls should they be? It's almost certainly the case that certain combinations of time control venues will work together better than others. There will always be the issue of waiting for games to complete and in fact this may make the problem a bit worse for those programs that only want to play in the longest venue. I suggest that each venue is spaced at least a factor of 2 apart in time. For instance 1 minute, 2 minutes, 4 minutes, etc. My own suggestion for 9x9 is to have 3 venues of 1 minute, 5 minutes and 15 minutes per game per player. It's also not too late to change our minds and not have venues if we think the disadvantages outweigh the advantages. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS
On Fri, Jun 05, 2009 at 03:49:11PM -0400, Don Dailey wrote: Handicap games opens a can of worms. Of course, any program is free to give its opponent any handicap it wants, by passing in the opening (if the opponent didn't pass last). It is up to the operator of the bot to decide when and how much handicap to give, and how to analyze the results. The handicap-giving program can play under a different name, so that for CGOS it looks like a totally separate entry, with its own rating. -H -- 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: [computer-go] New CGOS
On Sat, Jun 6, 2009 at 3:18 AM, Heikki Levantohei...@lsd.dk wrote: On Fri, Jun 05, 2009 at 03:49:11PM -0400, Don Dailey wrote: Handicap games opens a can of worms. Of course, any program is free to give its opponent any handicap it wants, by passing in the opening (if the opponent didn't pass last). It is up to the operator of the bot to decide when and how much handicap to give, and how to analyze the results. The handicap-giving program can play under a different name, so that for CGOS it looks like a totally separate entry, with its own rating. This has a few problems: * Let's say black plays on D4 and then white passes, to give some handicap. Now black passes and wins the game by n^2 points, according to Tromp-Taylor rules. * Similarly, if black tries to give some handicap and passes on the first move, white may pass and win the game by komi. * Even if everyone agrees to not do this and continue playing until at least both players have one stone on the board, what happens when two programs that give handicap meet each other? * Then there is the minor issue that a program might place the handicap stones differently if it knows how many stones it can place before the opponent starts playing. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS
Yes, there are lots of problem with this. And some of my bots will automatically pass if doing so gives it the immediate win, so already I know of one program that this will not work. As soon as you pass, the game is over. Of course CGOS could be modified with a rule not to end the game until each player has made at least one non-pass move, but that solves nothing unless all the bots were aware of this rule. Something that might be similar, would be a rule to play the first N moves randomly.It would be a true handicap, but it would not be a consistent handicap. For instance 3 random moves may turn out to be reasonably good, or quite horrible.Perhaps it would be reasonable to start with N non-corner random edge moves which might have a similar effect to pass moves.Or maybe the first N moves could be specified (to be weak moves) and the bot moves to each in turn, subject to it's availability. - Don On Sat, Jun 6, 2009 at 7:49 AM, Álvaro Begué alvaro.be...@gmail.com wrote: On Sat, Jun 6, 2009 at 3:18 AM, Heikki Levantohei...@lsd.dk wrote: On Fri, Jun 05, 2009 at 03:49:11PM -0400, Don Dailey wrote: Handicap games opens a can of worms. Of course, any program is free to give its opponent any handicap it wants, by passing in the opening (if the opponent didn't pass last). It is up to the operator of the bot to decide when and how much handicap to give, and how to analyze the results. The handicap-giving program can play under a different name, so that for CGOS it looks like a totally separate entry, with its own rating. This has a few problems: * Let's say black plays on D4 and then white passes, to give some handicap. Now black passes and wins the game by n^2 points, according to Tromp-Taylor rules. * Similarly, if black tries to give some handicap and passes on the first move, white may pass and win the game by komi. * Even if everyone agrees to not do this and continue playing until at least both players have one stone on the board, what happens when two programs that give handicap meet each other? * Then there is the minor issue that a program might place the handicap stones differently if it knows how many stones it can place before the opponent starts playing. Álvaro. ___ 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] New CGOS (was:Negative result on using MC as a predictor)
On Fri, Jun 05, 2009 at 11:19:51AM -0400, Don Dailey wrote: When I complete the new server, I hope that it will be easier to collect larger samples of games. I think this will help the situation a little. There will be multiple time controls, but they will be in sync, so that your program can always play in a shorter time control game without missing a game at the longer time control.The idea is to keep your bot busy while waiting for future rounds.You play in the longest time control, but when you are finished you can play fast games while waiting. I will have 2 or 3 levels of this, I haven't decided yet. If I have 3 levels, the slowest time control will probably need to be a little slower than CGOS uses now. That sounds fine for those bots that have implemented time controls. Simple-minded bots that just play a given number of simulations, or do other things in (more or less) constant time will loose the too fast games straight out. I suppose your server can ask the bot if it supports time controls, and only then let it play fast games. I will also have a test mode for new bots. The server itself will play test games with your bot while you debug it. Good idea! I have used cgos to debug my half-finished bots before, and felt a bit bad about wasting the time of more serious bots. -H -- 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: [computer-go] New CGOS (was:Negative result on using MC as a predictor)
On Fri, Jun 05, 2009 at 12:38:22PM -0400, Don Dailey wrote: You will be able to select which time controls you are willing to play - the server will not force you to play in all of them. Some may choose to play only fast games and other may not be able to play in the fast games, such as perhaps sluggo. Fine! -H -- 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: [computer-go] New CGOS
On Fri, Jun 5, 2009 at 12:36 PM, Michael Williams michaelwilliam...@gmail.com wrote: There will be multiple time controls, but they will be in sync, so that your program can always play in a shorter time control game without missing a game at the longer time control.The idea is to keep your bot busy while waiting for future rounds.You play in the longest time control, but when you are finished you can play fast games while waiting. I will have 2 or 3 levels of this, I haven't decided yet. If I have 3 levels, the slowest time control will probably need to be a little slower than CGOS uses now. That sounds fine for those bots that have implemented time controls. Simple-minded bots that just play a given number of simulations, or do other things in (more or less) constant time will loose the too fast games straight out. That's fine as long as the ratings are kept separate for each time control. The more I think about it, the more I think it's important that I keep ratings separate for each time control. - 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] New CGOS
Handicap games opens a can of worms. The last time we discussed it, it was difficult to get any kind of reasonable agreement on how to do it. There are many variations of rules with regard to handicap stones. On top of that, we have to think about how to rate such games. Of course there are advantages too. Scheduling should become simpler, but it wouldn't because even with handicap we should try to minimize the number of mismatched opponents. I think for now I want to not complicate it any more than I already have. I plan to do multiple board size and multiple time controls in the same server, that is enough for now. - Don 2009/6/5 Jason House jason.james.ho...@gmail.com On Jun 5, 2009, at 2:49 PM, Don Dailey dailey@gmail.com wrote: On Fri, Jun 5, 2009 at 12:36 PM, Michael Williams michaelwilliam...@gmail.com michaelwilliam...@gmail.com wrote: There will be multiple time controls, but they will be in sync, so that your program can always play in a shorter time control game without missing a game at the longer time control.The idea is to keep your bot busy while waiting for future rounds.You play in the longest time control, but when you are finished you can play fast games while waiting. I will have 2 or 3 levels of this, I haven't decided yet. If I have 3 levels, the slowest time control will probably need to be a little slower than CGOS uses now. That sounds fine for those bots that have implemented time controls. Simple-minded bots that just play a given number of simulations, or do other things in (more or less) constant time will loose the too fast games straight out. That's fine as long as the ratings are kept separate for each time control. The more I think about it, the more I think it's important that I keep ratings separate for each time control. - Don Any chance of handicap games when there is a large rating imbalance? ___ 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] New CGOS
The purpose of a handicap games is to allow a 50% chance of either contestant winning. If one program loses 100% of games against another, it would take a vast improvement to advance to 90% or 80%. If the same two programs have an appropriate handicap, and a base of 50% odds, it should be easier to see the beneficial impact of various changes. Contrast my winrate against a motley assortment of opponents, which changes month-to-month, is 3% higher than yours with my program can give yours two stones, and still win 50% of the games. Programs do not care, but their human designers might have an incentive to find a way to leapfrog over their opponents. Terry McIntyre terrymcint...@yahoo.com Any system of entrusting the government to judge and correct its own abuses is the same as appointing the accused criminal as his own judge and jury: don't expect many convictions. -- Allen Thornton, Laws of the Jungle From: Christoph Birk b...@ociw.edu To: computer-go computer-go@computer-go.org Sent: Friday, June 5, 2009 2:59:07 PM Subject: Re: [computer-go] New CGOS On Fri, 5 Jun 2009, Don Dailey wrote: Handicap games opens a can of worms. The last time we discussed it, it was difficult to get any kind of reasonable agreement on how to do it. Handicap games are for humans ... they get frustrated losing over and over. Computers have no problems with that. I agree with Don, adding a handicap server is an unnecessary complication. Christoph ___ 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] New CGOS
On Jun 5, 2009, at 5:59 PM, Christoph Birk b...@ociw.edu wrote: On Fri, 5 Jun 2009, Don Dailey wrote: Handicap games opens a can of worms. The last time we discussed it, it was difficult to get any kind of reasonable agreement on how to do it. Handicap games are for humans ... they get frustrated losing over and over. Computers have no problems with that. There are humans watching and reviewing the games. Handicap can give an unpredictable outcome, meaning both developers can look for small things to improve that could have changed the game outcome. Also, at least some bots on CGOS are intended for more than just games against computers. Having test data from handicap games could help refining how the bot handles such situations. I agree with Don, adding a handicap server is an unnecessary complication. It is a complication. I would be shocked if the first release of the new CGOS supported it. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS
On Fri, Jun 5, 2009 at 5:59 PM, Christoph Birk b...@ociw.edu wrote: Handicap games are for humans ... they get frustrated losing over and over. Computers have no problems with that. 2009/6/5 terry mcintyre terrymcint...@yahoo.com: The purpose of a handicap games is to allow a 50% chance of either contestant winning. A handicap system based on time controls could be appropriate for many computer programs. Not that I expect Don to implement any such thing any time soon. I just think that it is worth mentioning. Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] New CGOS client that allows multiple engines
We have designed a new CGOS engine client that has more features and should be more convenient to use. Here are the primary new features: 1. You can run multiple engines if you choose. 2. You can specify server and port. 3. Works with configuration file - so you have multiple configs for different testing scenarios. I would like volunteers to test the alpha version so that we can get useful feedback. The feedback we are most interested in concerns bugs, glitches, annoyances that can be easily fixed, not ideas for major upgrades. If you have great ideas for future features, go to sourceforge and join the cgos-developers and we would welcome your feedback on this. It would be useful to test this on unix, windows and macs. I have done some testing on Unix, but want to know especially if there are Windows and Mac issues although I hope for good coverage on all platforms. The new client supports multiple engines, but does not manage simultaneous games with these engines, instead it manages the rotation of any specified number of players. So you may have several players taking turns playing games on CGOS. The players are selected randomly but you can choose the priority, for instance setting one player up to play twice as often as another if you choose. The priority number is a positive integer (it can be zero to deactivate a player) and determines how often a given player will play. The rotation schedule is not predictable, it is probabilistic so if you do set one program to play twice as often as another, this will happen on average, but it won't be a predictable cycle. The probability of a particular engine playing the next game is computed like this: prob = p / s where s is the sum of all the engines priority numbers and p is the priority of the engine in question. The client manages the connections - determining when to log on and off the server to connect a different program so that they can be rotated in a proper way. The client reads the configuration file between rounds, so you can even modify priorities or who plays between rounds without restarting the client or temporarily deactivate a player by setting his priority to zero. To run the client just execute it without arguments to get a usage message which explains everything. The alpha client version can be found here: http://cgos.boardspace.net/public/cgosGtp_alpha.zip Currently only a pure tcl version is available but we will be packaging these up as executables for the various platforms soon. Or on request we can do this right away. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS client that allows multiple engines
Don, Although I'm not interested in this feature at this point in time I applaud the effort you put into this server. Just some information with regards to Mac clients: it turns out Macs come with a tcl runtime out of the box. So you should point Mac users simply to the cgos3.tcl file and they'll be fine. It would have saved me a little bit of fuss. Oh, and the fact that it has to be started with ./cgos3.tcl, simply cgos3.tcl doesn't work. But maybe that's just showing I hardly ever use the command-line shell. Mark On 16-jan-08, at 13:55, Don Dailey wrote: We have designed a new CGOS engine client that has more features and should be more convenient to use. Here are the primary new features: You can run multiple engines if you choose. You can specify server and port. Works with configuration file - so you have multiple configs for different testing scenarios. I would like volunteers to test the alpha version so that we can get useful feedback. The feedback we are most interested in concerns bugs, glitches, annoyances that can be easily fixed, not ideas for major upgrades. If you have great ideas for future features, go to sourceforge and join the cgos-developers and we would welcome your feedback on this. It would be useful to test this on unix, windows and macs. I have done some testing on Unix, but want to know especially if there are Windows and Mac issues although I hope for good coverage on all platforms. The new client supports multiple engines, but does not manage simultaneous games with these engines, instead it manages the rotation of any specified number of players. So you may have several players taking turns playing games on CGOS. The players are selected randomly but you can choose the priority, for instance setting one player up to play twice as often as another if you choose. The priority number is a positive integer (it can be zero to deactivate a player) and determines how often a given player will play. The rotation schedule is not predictable, it is probabilistic so if you do set one program to play twice as often as another, this will happen on average, but it won't be a predictable cycle. The probability of a particular engine playing the next game is computed like this: prob = p / s where s is the sum of all the engines priority numbers and p is the priority of the engine in question. The client manages the connections - determining when to log on and off the server to connect a different program so that they can be rotated in a proper way. The client reads the configuration file between rounds, so you can even modify priorities or who plays between rounds without restarting the client or temporarily deactivate a player by setting his priority to zero. To run the client just execute it without arguments to get a usage message which explains everything. The alpha client version can be found here: http://cgos.boardspace.net/public/cgosGtp_alpha.zip Currently only a pure tcl version is available but we will be packaging these up as executables for the various platforms soon. Or on request we can do this right away. - 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] new CGOS
On Tue, Mar 20, 2007 at 05:46:12PM -0400, Don Dailey wrote: The new cgos has a slightly better look: Looks promising! I need volunteers for testing. If you want to enter your bot on the new server as a test, feel free. I will try to set halgo up to play there. I will be making some minor changes to the protocol which will eventually break the client - but this client will work for a day or two: http://www.greencheeks.homelinux.org:8015/~drd/public/cgos3.tcl Does it have the same feature, as teh perl client did - that I can see what my program outputs on stderr ? I liked to see what was going on, and put all my debug info there. Or do I have to pipe it into a file, and have a tail -f on that file? Can do that, of course. 4. Ratings appear instantly (starts at 1200) but won't be accurate - at least you can watch it change. Would it be possible to display a rating +/- uncertainty, so as to make this visible? -H -- 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: [computer-go] new CGOS
It's going to be down for a couple of days while I catch up on other work - but I will want to put it for testing again later. I may put up the test version as a 2 minute server and try to get a lot of programs to hammer it. Of course I don't care about the quality of the bots in this test case. - Don On Fri, 2007-03-23 at 09:30 +0100, Heikki Levanto wrote: On Tue, Mar 20, 2007 at 05:46:12PM -0400, Don Dailey wrote: The new cgos has a slightly better look: Looks promising! I need volunteers for testing. If you want to enter your bot on the new server as a test, feel free. I will try to set halgo up to play there. I will be making some minor changes to the protocol which will eventually break the client - but this client will work for a day or two: http://www.greencheeks.homelinux.org:8015/~drd/public/cgos3.tcl Does it have the same feature, as teh perl client did - that I can see what my program outputs on stderr ? I liked to see what was going on, and put all my debug info there. Or do I have to pipe it into a file, and have a tail -f on that file? Can do that, of course. 4. Ratings appear instantly (starts at 1200) but won't be accurate - at least you can watch it change. Would it be possible to display a rating +/- uncertainty, so as to make this visible? -H ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] new CGOS
We have a scheduled power outage this weekend. If you still need a bot on Monday we will put up a SlugGo. Cheers, David On 20, Mar 2007, at 2:46 PM, Don Dailey wrote: I need volunteers for testing. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] new CGOS
On Tue, Mar 20, 2007 at 05:46:12PM -0400, Don Dailey wrote: I need volunteers for testing. If you want to enter your bot on the new server as a test, feel free.I will be making some minor changes to the protocol which will eventually break the client - but this client will work for a day or two: http://www.greencheeks.homelinux.org:8015/~drd/public/cgos3.tcl 404 - not found -- 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: [computer-go] new CGOS
I took the binary down, because it's no longer compatible - I made a couple of changes and I'm no longer testing the server anyway. However, I will be testing the server again later and will put up a new client when I'm ready. Right now I have to take care of some other obligations.I'll send out a message when I am ready to test again. I'm hoping this will be on Monday. - Don On Fri, 2007-03-23 at 20:13 +0100, Heikki Levanto wrote: On Tue, Mar 20, 2007 at 05:46:12PM -0400, Don Dailey wrote: I need volunteers for testing. If you want to enter your bot on the new server as a test, feel free.I will be making some minor changes to the protocol which will eventually break the client - but this client will work for a day or two: http://www.greencheeks.homelinux.org:8015/~drd/public/cgos3.tcl 404 - not found ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] new CGOS
The new cgos has a slightly better look: http://www.greencheeks.homelinux.org:8015/~drd/CGOS/ The links to the crosstable not quite there yet, but the crosstable looks like this: http://www.greencheeks.homelinux.org:8015/~drd/CGOS/cross/AnchorFat.html I need volunteers for testing. If you want to enter your bot on the new server as a test, feel free.I will be making some minor changes to the protocol which will eventually break the client - but this client will work for a day or two: http://www.greencheeks.homelinux.org:8015/~drd/public/cgos3.tcl Some features: 1. if your bot gets disconnected, just log back on and you can finish the game without losing, assuming you have enough time left. 2. The client knows who the opponent is and what his rating is before the game begins. But it's not reported yet in any meaningful way. If you hack the client (it's pretty simple) you can get to that info for the time being. 3. crosstable shows opponents ratings. 4. Ratings appear instantly (starts at 1200) but won't be accurate - at least you can watch it change. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New CGOS
On Sat, 2007-02-03 at 14:41 -0500, Chris Fant wrote: Don, How is the new version of cgos coming along? From what I understood, you were very close to finished, but didn't have much time to devote to it. It's currently on hold. I'm worried about having a good cross-platform viewing client. The one I have is written in tcl/TK and I can produce exe files for windows users. But I ran into some difficulties with some linux versions using tclkit's which is how I package them. So I'm still contemplating (and procrastnating) how to proceed. I'm also consider wxWidgets or GTK+ which are both cross-platform. I'm also considering whether to support multiple levels and/or boardsizes and perhaps a couple of other nice features. The latest version actually works - you can play games and watch them in real time with a very nice viewing client - but it is not quite there yet - there is no web reporting yet. - Don (Excuse the incorrect subject on my previous thread, Details of AnchorMan -- I was originally going to ask about Anchorman, but then decided GenericMC_1000 was a better first try). ___ 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] New CGOS
Are you going to release the source for it? If you are, some of us might be able to make some suggestions for how to port it to various platforms. Just a thought. BTW, I know that I appreciate the work you are putting in and I'm sure others are as well. - Nick On 2/3/07, Don Dailey [EMAIL PROTECTED] wrote: On Sat, 2007-02-03 at 14:41 -0500, Chris Fant wrote: Don, How is the new version of cgos coming along? From what I understood, you were very close to finished, but didn't have much time to devote to it. It's currently on hold. I'm worried about having a good cross-platform viewing client. The one I have is written in tcl/TK and I can produce exe files for windows users. But I ran into some difficulties with some linux versions using tclkit's which is how I package them. So I'm still contemplating (and procrastnating) how to proceed. I'm also consider wxWidgets or GTK+ which are both cross-platform. I'm also considering whether to support multiple levels and/or boardsizes and perhaps a couple of other nice features. The latest version actually works - you can play games and watch them in real time with a very nice viewing client - but it is not quite there yet - there is no web reporting yet. - Don (Excuse the incorrect subject on my previous thread, Details of AnchorMan -- I was originally going to ask about Anchorman, but then decided GenericMC_1000 was a better first try). ___ 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] New CGOS
On Sat, 2007-02-03 at 19:18 -0600, Nick Apperson wrote: Are you going to release the source for it? If you are, some of us might be able to make some suggestions for how to port it to various platforms. Just a thought. BTW, I know that I appreciate the work you are putting in and I'm sure others are as well. - Nick On 2/3/07, Don Dailey [EMAIL PROTECTED] wrote: On Sat, 2007-02-03 at 14:41 -0500, Chris Fant wrote: Don, How is the new version of cgos coming along? From what I understood, you were very close to finished, but didn't have much time to devote to it. It's currently on hold. I'm worried about having a good cross-platform viewing client. The one I have is written in tcl/TK and I can produce exe files for windows users. But I ran into some difficulties with some linux versions using tclkit's which is how I package them. So I'm still contemplating (and procrastnating) how to proceed. I'm also consider wxWidgets or GTK+ which are both cross-platform. I'm also considering whether to support multiple levels and/or boardsizes and perhaps a couple of other nice features. The latest version actually works - you can play games and watch them in real time with a very nice viewing client - but it is not quite there yet - there is no web reporting yet. - Don (Excuse the incorrect subject on my previous thread, Details of AnchorMan -- I was originally going to ask about Anchorman, but then decided GenericMC_1000 was a better first try). ___ 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] New CGOS
On Sat, 2007-02-03 at 19:18 -0600, Nick Apperson wrote: Are you going to release the source for it? If you are, some of us might be able to make some suggestions for how to port it to various platforms. Just a thought. BTW, I know that I appreciate the work you are putting in and I'm sure others are as well. I didn't expect it to be such a success. But it needs a face-lift and some improvements. In some ways it's a big dirty hack and I want to fix this. - Don - Nick On 2/3/07, Don Dailey [EMAIL PROTECTED] wrote: On Sat, 2007-02-03 at 14:41 -0500, Chris Fant wrote: Don, How is the new version of cgos coming along? From what I understood, you were very close to finished, but didn't have much time to devote to it. It's currently on hold. I'm worried about having a good cross-platform viewing client. The one I have is written in tcl/TK and I can produce exe files for windows users. But I ran into some difficulties with some linux versions using tclkit's which is how I package them. So I'm still contemplating (and procrastnating) how to proceed. I'm also consider wxWidgets or GTK+ which are both cross-platform. I'm also considering whether to support multiple levels and/or boardsizes and perhaps a couple of other nice features. The latest version actually works - you can play games and watch them in real time with a very nice viewing client - but it is not quite there yet - there is no web reporting yet. - Don (Excuse the incorrect subject on my previous thread, Details of AnchorMan -- I was originally going to ask about Anchorman, but then decided GenericMC_1000 was a better first try). ___ 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/
