Re: [computer-go] GTPv3
It would be nice to have a reference implementation. I can do that on Java (yes Its not C but its reference implementation and for free, I would do a lot of JUnits in exchange). What do you think ? --- £ukasz Lew [EMAIL PROTECTED] escribió: Hi, There are some issues that are not so well defined in GTP v2. Maybe GTP v3 should be released to avoid too much legacy later? 1. The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For instance When he want to send commands to GUI to draw something while he is working. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent - syntax is not standardized - there is no confirmation about success / failure for those commands. 2. The second thing is that there are many variables in the engine (komi, board size, time, etc). Developers tend to have more of them to control various parameters of the engine. End users could like to have some control over strength of the algorithm, etc. 3. If GTP would supports chats, KGS would probably implement it. 4. Opponent identification. 5. Interrupt. Users do not always want to wait until the program finish work. GoGui uses comment #interrupt to do it, but this is a hack. (this is somewhat related to 1.) 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. Would You like to have those issues solved? I hope we can get somewhere. :) Best Regards, £ukasz ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How did MoGo do it?
Hello Peter, Hello Don, Hello all, It is true that I have been mainly working to improve the level of MoGo in 19x19. It turned out in my experiments, that improving its level in 9x9 with very little simulations was significant for the level in 19x19, so it is one reason why the limited version of MoGo are running on cgos. So even if the goal was 19x19 improvements, the improvements appeared in all boardsizes. Our first approach to 19x19 was, as you say Don, to constrain the board (as explained in our paper), and it brought improvements. However, now it is quite the contrary what is happening, each improvement allows to remove constrains on 19x19, and making it play as if it was a 9x9 board (I mean in the parameters). As you may have noticed for example, MoGo is not playing locally anymore on 19x19 (which gives it an ugly style :-)). The number of simulations done in this tournament was from 10k to 50k per move, depending on the context and the move number (simple time management stopping early the thinking if one move is clearly better than the others). For all the details on the improvements, we submitted a paper, and I am writing them in my thesis, so you will all know, just wait for them to be written :-/. I still strongly believe in the future of MC even in 19x19. Bye, Sylvain 2007/3/5, Don Dailey [EMAIL PROTECTED]: I'm pretty sure I read that the MoGo team is shifting their efforts towards 19x19 GO. There are lot's of possibilites for research, but Mogo already does things to constrain the board on 19x19, they are probably just refining this stuff. - Don On Sun, 2007-03-04 at 19:58 -0800, Peter Drake wrote: Congratulations to MoGo on winning the KGS tournament held earlier today: http://www.gokgs.com/tournEntrants.jsp?sort=sid=270 Even under borderline blitz conditions (18 minutes sudden death for 19x19), MoGo managed to beat conventional programs like GNU Go. (ManyFaces apparently had some connection/restarting glitch, so its performance may not be representative.) Of course, MoGo also beat all the other MC/UCT programs. How did MoGo do it? I have three hypotheses: 1) MoGo is completing more runs per second. How many is it doing on the machine used in the tournament. 2) MoGo is somehow getting more out of the runs it does, using things like the all-as-first heuristic. 3) Each of MoGo's runs is smarter, through the use of heuristics that bias the random games. My money is on #3. In the limit, of course, a very smart program could predict the outcome with one MC run for each move under consideration. Would the MoGo authors (and anyone else) care to weigh in? Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents --- £ukasz Lew [EMAIL PROTECTED] escribió: On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] wrote: On Thu March 1 2007 05:22, £ukasz Lew wrote: The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For these requests come up once in a while, but IMO the clear separation between who is the controller and the engine is a big advantage of GTP. It makes both the implementation of engines and controllers much easier. I agree Can you do simple, single-threaded controller scripts with UCI? Is it used for as many use cases as GTP is, ranging from regression testing to any kind of automated experiments with Go engines? The Go server protocols are designed for humans and asynchronous sending of messages between them at any time, but does it make sense for a computer engine to allow it to start chatting, whenever it feels like it? I think it is sometimes important to allow the engine to sent some information including chatting. I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. I agree. So is there any solution not using stderr? In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent Remi Coulom convinced me that it is more convenient for the engine to write to standard error and he was right. Typically the GTP interface is only one of several interfaces to lower level Go engine code and you don't want to make lower level code aware of this. I would like to have GTP flexible enough to be the only interface needed. One idea I had in mind to address this was to allow the engine to send comment lines before the actual response. Then you could tunnel the standard error output through a network connection in these comment lines, maybe starting with a special keyword. That is interesting. But why before the actual response? It should be allowed to sent it any time, and it's a matter of server implementation when It will parse it. It would need only a minor modification to existing controllers to ignore all text before the response. Alternatively, one could extend the tools GtpServer and NetGtp in the GoGui package to internally transmit standard error text in such a way, that would be transparent for the engine and controller on different hosts. 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. The coming version 1.0 of GoGui will support a setup command. It is a simplified version of a suggestion I made a while ago to the GTP list and uses a syntax like: gogui-setup b A1 b B2 w C3 Originally I had an undoable setup command in mind to incrementally follow setup stones in SGF trees, but it is much easier for engine programmers to handle only full position setup on empty boards, so GoGui will follow the SGF properties incrementally and translate setup nodes into clear_board / gogui-setup sequences. - Markus ___ 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/ __ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes it's mind about the move choice, it's current opinion of the score, etc. This can be implemented with polling by adding a GTP command to request information from the engine every second or two, but this feels like a hack. Thinking on the opponents time (pondering) is supported naturally by the UCI protocol. Actually, the engine doesn't need to know much about this, the controller simply tells the engine to start thinking on a given move and so the engine doesn't even know it's thinking on the opponents time. However, the engine does communicate to the controller what the ponder move is. This could ALMOST be implemented directly in GTP, except for the fact that you cannot stop the engine from searching once it begins. If I'm pondering, but the opponent doesn't play the ponder move, there is not way in GTP to say, STOP searching NOW because the move is not relevant! So GTP could not easily be used to build a high quality user interface, say for a commercial program. At least not one that had the better features, even given that you can extend the command set with additional commands. It COULD be done, just not easily. You would have to do it all with polling. You could even implement stop search by having a GTP command to do searching in tiny time slices. The contoller would send commands such as continue_search which must return in a fraction of second, possibly with a move.This would be truly awkward but possible. - Don On Thu, 2007-03-01 at 17:10 -0700, Markus Enzenberger wrote: On Thu March 1 2007 05:22, £ukasz Lew wrote: The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For these requests come up once in a while, but IMO the clear separation between who is the controller and the engine is a big advantage of GTP. It makes both the implementation of engines and controllers much easier. Can you do simple, single-threaded controller scripts with UCI? Is it used for as many use cases as GTP is, ranging from regression testing to any kind of automated experiments with Go engines? The Go server protocols are designed for humans and asynchronous sending of messages between them at any time, but does it make sense for a computer engine to allow it to start chatting, whenever it feels like it? I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent Remi Coulom convinced me that it is more convenient for the engine to write to standard error and he was right. Typically the GTP interface is only one of several interfaces to lower level Go engine code and you don't want to make lower level code aware of this. One idea I had in mind to address this was to allow the engine to send comment lines before the actual response. Then you could tunnel the standard error output through a network connection in these comment lines, maybe starting with a special keyword. It would need only a minor modification to existing controllers to ignore all text before the response. Alternatively, one could extend the tools GtpServer and NetGtp in the GoGui package to internally transmit standard error text in such a way, that would be transparent for the engine and controller on different hosts. 6. Position setup. I had conversation
Re: [computer-go] GTPv3
I think you are mostly correct. But, the problem is that GTP was designed to block on the genmove command. This is a problem because genmove is usually not quick to return. Therefore, there is no way with the current scheme to be able to issue commands while an engine is thinking. It would require a redesign perhaps using polling instead if GTP is to remain blocking. On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes it's mind about the move choice, it's current opinion of the score, etc. This can be implemented with polling by adding a GTP command to request information from the engine every second or two, but this feels like a hack. Thinking on the opponents time (pondering) is supported naturally by the UCI protocol. Actually, the engine doesn't need to know much about this, the controller simply tells the engine to start thinking on a given move and so the engine doesn't even know it's thinking on the opponents time. However, the engine does communicate to the controller what the ponder move is. This could ALMOST be implemented directly in GTP, except for the fact that you cannot stop the engine from searching once it begins. If I'm pondering, but the opponent doesn't play the ponder move, there is not way in GTP to say, STOP searching NOW because the move is not relevant! So GTP could not easily be used to build a high quality user interface, say for a commercial program. At least not one that had the better features, even given that you can extend the command set with additional commands. It COULD be done, just not easily. You would have to do it all with polling. You could even implement stop search by having a GTP command to do searching in tiny time slices. The contoller would send commands such as continue_search which must return in a fraction of second, possibly with a move.This would be truly awkward but possible. - Don On Thu, 2007-03-01 at 17:10 -0700, Markus Enzenberger wrote: On Thu March 1 2007 05:22, £ukasz Lew wrote: The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For these requests come up once in a while, but IMO the clear separation between who is the controller and the engine is a big advantage of GTP. It makes both the implementation of engines and controllers much easier. Can you do simple, single-threaded controller scripts with UCI? Is it used for as many use cases as GTP is, ranging from regression testing to any kind of automated experiments with Go engines? The Go server protocols are designed for humans and asynchronous sending of messages between them at any time, but does it make sense for a computer engine to allow it to start chatting, whenever it feels like it? I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent Remi Coulom convinced me that it is more convenient for the engine to write to standard error and he was right. Typically the GTP interface is only one of several interfaces to lower level Go engine code and you don't want to make lower level code aware of this. One idea I had in mind to address this was to allow the engine to send comment lines before the actual response. Then you could tunnel the standard error output through a network connection in these comment lines, maybe starting with a special keyword.
Re: [computer-go] GTPv3
Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link. you can have a couple of sub commands for get_move like: get_complete_percent, get_current_best_move, chat, etc. If the engine doesn't support realtime gtp, they will be answer after the gen_move response. one at a time. I don't know, perhaps I'm pushing too much the gtp protocol... I don't think so, but perhaps --- Nick Apperson [EMAIL PROTECTED] escribió: I think you are mostly correct. But, the problem is that GTP was designed to block on the genmove command. This is a problem because genmove is usually not quick to return. Therefore, there is no way with the current scheme to be able to issue commands while an engine is thinking. It would require a redesign perhaps using polling instead if GTP is to remain blocking. On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes it's mind about the move choice, it's current opinion of the score, etc. This can be implemented with polling by adding a GTP command to request information from the engine every second or two, but this feels like a hack. Thinking on the opponents time (pondering) is supported naturally by the UCI protocol. Actually, the engine doesn't need to know much about this, the controller simply tells the engine to start thinking on a given move and so the engine doesn't even know it's thinking on the opponents time. However, the engine does communicate to the controller what the ponder move is. This could ALMOST be implemented directly in GTP, except for the fact that you cannot stop the engine from searching once it begins. If I'm pondering, but the opponent doesn't play the ponder move, there is not way in GTP to say, STOP searching NOW because the move is not relevant! So GTP could not easily be used to build a high quality user interface, say for a commercial program. At least not one that had the better features, even given that you can extend the command set with additional commands. It COULD be done, just not easily. You would have to do it all with polling. You could even implement stop search by having a GTP command to do searching in tiny time slices. The contoller would send commands such as continue_search which must return in a fraction of second, possibly with a move.This would be truly awkward but possible. - Don On Thu, 2007-03-01 at 17:10 -0700, Markus Enzenberger wrote: On Thu March 1 2007 05:22, £ukasz Lew wrote: The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For these requests come up once in a while, but IMO the clear separation between who is the controller and the engine is a big advantage of GTP. It makes both the implementation of engines and controllers much easier. Can you do simple, single-threaded controller scripts with UCI? Is it used for as many use cases as GTP is, ranging from regression testing to any kind of automated experiments with Go engines? The Go server protocols are designed for humans and asynchronous sending of messages between them at any time, but does it make sense for a computer engine to allow it to start chatting, whenever it feels like it? I think
Re: [computer-go] GTPv3
On Mon, Mar 05, 2007 at 09:50:30AM -0300, Eduardo Sabbatella wrote: Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link. Yes. That is not a bug, it is a feature, when using GTP for debugging, automatic tests, or something else that is based on scripts. As has been said before, it would be possible to add a command like 'start-thinking', which would return quickly, while the engine would be thinking in the background. While in this state, more asynchrnous commands could be issued. Perhaps the engine could also send status responses and/or chat messages without a status request. If an engine (or controller) does not support the new commands, they can always fall back to the old, synchronous, commands. If the engine doesn't support realtime gtp, they will be answer after the gen_move response. one at a time. I think it would be better to create new commands, and leave genmove as it is, for maximizing the compatibility with old programs, and with new ones that haven't got around to implementing the asynch stuff yet. - 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: [computer-go] GTPv3
On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote: On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote: And you CAN compare GTP directly to UCI because both are designed for the same purpose and both are simple text based protocols and the similarities are much greater than the differences. GTP has many purposes. One of them is to sit betwene an engine and an UI, but that is not the only one. It is also used for test scripts to validate engines, and to debug them. So, what even asynchronous extensions you are adding to GTP, please keep the simple synchronous mode still available, for it has many uses too! If I were designing the asynchronous extentions I was mandate that the core doesn't change - that you can continue to use GTP as is without any suprises. - Don -Heikki ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How did MoGo do it?
Sylvain, What you say is no surpise to me about the constraints. I knew that if you improved things, you would eventually have to improve or reduce the constraints. The simple question I always ask about a feature is whether the idea is infinitely scalable. Some idea are very good in the short term, but in the long term form a barrier to improvement. Of course that doesn't mean the idea shouldn't be used because it might be helping you. But at some point you know your program will out-grow the idea and then it will be holding you back. A good example of this is piece square tables in computer chess. It was a wonderful way to add a lot of knowledge to a chess program without slowing it down any. It's based on the idea of looking at the starting position, making a lot of stategic decisions before you even begin searching (by filling the table with values) and then doing the search. This idea has serious limitation when you search incredibly deep, but really worked well in the days when programs could not search deeply. I think some programs still use this today but to a lesser extent - they have adjusted accordingly with much more dynamic evaluation. I have this theory that if something isn't properly scalable, then you are probably doing it wrong - at least in an idealistic sense. From a practical standpoint I have no trouble doing these non-scalable things if there is no obvious scalable solution that can give me the same short-term improvement. AnchorMan is a clear example of this non-scalable approach. A hackery of non-scalable patches to try to stop it from playing the ugliest of moves! - Don On Mon, 2007-03-05 at 10:52 +0100, Sylvain Gelly wrote: Hello Peter, Hello Don, Hello all, It is true that I have been mainly working to improve the level of MoGo in 19x19. It turned out in my experiments, that improving its level in 9x9 with very little simulations was significant for the level in 19x19, so it is one reason why the limited version of MoGo are running on cgos. So even if the goal was 19x19 improvements, the improvements appeared in all boardsizes. Our first approach to 19x19 was, as you say Don, to constrain the board (as explained in our paper), and it brought improvements. However, now it is quite the contrary what is happening, each improvement allows to remove constrains on 19x19, and making it play as if it was a 9x9 board (I mean in the parameters). As you may have noticed for example, MoGo is not playing locally anymore on 19x19 (which gives it an ugly style :-)). The number of simulations done in this tournament was from 10k to 50k per move, depending on the context and the move number (simple time management stopping early the thinking if one move is clearly better than the others). For all the details on the improvements, we submitted a paper, and I am writing them in my thesis, so you will all know, just wait for them to be written :-/. I still strongly believe in the future of MC even in 19x19. Bye, Sylvain 2007/3/5, Don Dailey [EMAIL PROTECTED]: I'm pretty sure I read that the MoGo team is shifting their efforts towards 19x19 GO. There are lot's of possibilites for research, but Mogo already does things to constrain the board on 19x19, they are probably just refining this stuff. - Don On Sun, 2007-03-04 at 19:58 -0800, Peter Drake wrote: Congratulations to MoGo on winning the KGS tournament held earlier today: http://www.gokgs.com/tournEntrants.jsp?sort=sid=270 Even under borderline blitz conditions (18 minutes sudden death for 19x19), MoGo managed to beat conventional programs like GNU Go. (ManyFaces apparently had some connection/restarting glitch, so its performance may not be representative.) Of course, MoGo also beat all the other MC/UCT programs. How did MoGo do it? I have three hypotheses: 1) MoGo is completing more runs per second. How many is it doing on the machine used in the tournament. 2) MoGo is somehow getting more out of the runs it does, using things like the all-as-first heuristic. 3) Each of MoGo's runs is smarter, through the use of heuristics that bias the random games. My money is on #3. In the limit, of course, a very smart program could predict the outcome with one MC run for each move under consideration. Would the MoGo authors (and anyone else) care to weigh in? Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org
Re: [computer-go] How did MoGo do it?
Also sometimes it scales but not lineal, thats an issue to. A big one. Like raw MC, you can get a very good move with less than 70k simulations, to get a really good move perhaps you need 400 billons. I remember there is a paper about this with a 'oracle' MC engine and they used it to compare to different mc implementations. MC oracle was a MC engine running like 100 billon simulations for every move. --- Don Dailey [EMAIL PROTECTED] escribió: Sylvain, What you say is no surpise to me about the constraints. I knew that if you improved things, you would eventually have to improve or reduce the constraints. The simple question I always ask about a feature is whether the idea is infinitely scalable. Some idea are very good in the short term, but in the long term form a barrier to improvement. Of course that doesn't mean the idea shouldn't be used because it might be helping you. But at some point you know your program will out-grow the idea and then it will be holding you back. A good example of this is piece square tables in computer chess. It was a wonderful way to add a lot of knowledge to a chess program without slowing it down any. It's based on the idea of looking at the starting position, making a lot of stategic decisions before you even begin searching (by filling the table with values) and then doing the search. This idea has serious limitation when you search incredibly deep, but really worked well in the days when programs could not search deeply. I think some programs still use this today but to a lesser extent - they have adjusted accordingly with much more dynamic evaluation. I have this theory that if something isn't properly scalable, then you are probably doing it wrong - at least in an idealistic sense. From a practical standpoint I have no trouble doing these non-scalable things if there is no obvious scalable solution that can give me the same short-term improvement. AnchorMan is a clear example of this non-scalable approach. A hackery of non-scalable patches to try to stop it from playing the ugliest of moves! - Don On Mon, 2007-03-05 at 10:52 +0100, Sylvain Gelly wrote: Hello Peter, Hello Don, Hello all, It is true that I have been mainly working to improve the level of MoGo in 19x19. It turned out in my experiments, that improving its level in 9x9 with very little simulations was significant for the level in 19x19, so it is one reason why the limited version of MoGo are running on cgos. So even if the goal was 19x19 improvements, the improvements appeared in all boardsizes. Our first approach to 19x19 was, as you say Don, to constrain the board (as explained in our paper), and it brought improvements. However, now it is quite the contrary what is happening, each improvement allows to remove constrains on 19x19, and making it play as if it was a 9x9 board (I mean in the parameters). As you may have noticed for example, MoGo is not playing locally anymore on 19x19 (which gives it an ugly style :-)). The number of simulations done in this tournament was from 10k to 50k per move, depending on the context and the move number (simple time management stopping early the thinking if one move is clearly better than the others). For all the details on the improvements, we submitted a paper, and I am writing them in my thesis, so you will all know, just wait for them to be written :-/. I still strongly believe in the future of MC even in 19x19. Bye, Sylvain 2007/3/5, Don Dailey [EMAIL PROTECTED]: I'm pretty sure I read that the MoGo team is shifting their efforts towards 19x19 GO. There are lot's of possibilites for research, but Mogo already does things to constrain the board on 19x19, they are probably just refining this stuff. - Don On Sun, 2007-03-04 at 19:58 -0800, Peter Drake wrote: Congratulations to MoGo on winning the KGS tournament held earlier today: http://www.gokgs.com/tournEntrants.jsp?sort=sid=270 Even under borderline blitz conditions (18 minutes sudden death for 19x19), MoGo managed to beat conventional programs like GNU Go. (ManyFaces apparently had some connection/restarting glitch, so its performance may not be representative.) Of course, MoGo also beat all the other MC/UCT programs. How did MoGo do it? I have three hypotheses: 1) MoGo is completing more runs per second. How many is it doing on the machine used in the tournament. 2) MoGo is somehow getting more out of the runs it does, using things like the all-as-first heuristic. 3) Each of MoGo's runs is smarter, through the use of heuristics that bias the random games. My money is on #3. In the limit, of course, a very smart program could predict the outcome with one MC run for each
Re: [computer-go] GTPv3
I agree with you. My idea is to not have a specific aync command, but to have anycronous versions of commands. The engine is free to accept or reject them. Having an async command doesn't do anything if you haven't implemented the useful needed extensions.Of course it could change the meaning of existing commands but I think it's cleaner to simply have new GTP commands that are understood to be asyncrounous. Even UCI doesn't allow the engine to say anything it wants whenever it wants. It is still semi-syncronous. All communication sent from an engine is still a response to some command sent from the controller. The rule is that you ignore any communication sent out of context and this avoids syncronization issues such as when the controller says to stop searching but the engine sends a move before this is noticed. So it's really not as complicated as you might think. chat I assume is about informational messages from a searching engine. So it's a legitimate response to an asyncronous command to search a position, but if you are not searching a position it would be ignored by the controller. Abort is the same, it really means stop searching if you are currently searching and so is ignored if you happen to have stopped at almost the same instant you recieved the command. - Don On Mon, 2007-03-05 at 09:08 -0300, Eduardo Sabbatella wrote: Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
We got consensus :-) Yes some messages are async, some are synqued. If an async message/reply is received in the wrong time, it could be ignored as they use to be information only values, no state change of the game. cool :-) --- Don Dailey [EMAIL PROTECTED] escribió: I agree with you. My idea is to not have a specific aync command, but to have anycronous versions of commands. The engine is free to accept or reject them. Having an async command doesn't do anything if you haven't implemented the useful needed extensions.Of course it could change the meaning of existing commands but I think it's cleaner to simply have new GTP commands that are understood to be asyncrounous. Even UCI doesn't allow the engine to say anything it wants whenever it wants. It is still semi-syncronous. All communication sent from an engine is still a response to some command sent from the controller. The rule is that you ignore any communication sent out of context and this avoids syncronization issues such as when the controller says to stop searching but the engine sends a move before this is noticed. So it's really not as complicated as you might think. chat I assume is about informational messages from a searching engine. So it's a legitimate response to an asyncronous command to search a position, but if you are not searching a position it would be ignored by the controller. Abort is the same, it really means stop searching if you are currently searching and so is ignored if you happen to have stopped at almost the same instant you recieved the command. - Don On Mon, 2007-03-05 at 09:08 -0300, Eduardo Sabbatella wrote: Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
just a thought... prefix all async commands with async_ so that it is clear. Also, that way there can be a version of the command that is async and one that blocks and an engine can support one or both. This could be useful for commands that query on state (or estimated score or whatever). An engine might not be able to easily support that async, but another engine might be able to. The controller can query using get_commands (or whatever the function is called) and know that it can call it anytime or only when the engine isn't thinking. Also, it would make it clearer how a command operates and a command can be assumed to be blocking unless it has that prefix and if we change the behavior of the async versions from the blocking ones an engine can still support both. - Nick On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: We got consensus :-) Yes some messages are async, some are synqued. If an async message/reply is received in the wrong time, it could be ignored as they use to be information only values, no state change of the game. cool :-) --- Don Dailey [EMAIL PROTECTED] escribió: I agree with you. My idea is to not have a specific aync command, but to have anycronous versions of commands. The engine is free to accept or reject them. Having an async command doesn't do anything if you haven't implemented the useful needed extensions.Of course it could change the meaning of existing commands but I think it's cleaner to simply have new GTP commands that are understood to be asyncrounous. Even UCI doesn't allow the engine to say anything it wants whenever it wants. It is still semi-syncronous. All communication sent from an engine is still a response to some command sent from the controller. The rule is that you ignore any communication sent out of context and this avoids syncronization issues such as when the controller says to stop searching but the engine sends a move before this is noticed. So it's really not as complicated as you might think. chat I assume is about informational messages from a searching engine. So it's a legitimate response to an asyncronous command to search a position, but if you are not searching a position it would be ignored by the controller. Abort is the same, it really means stop searching if you are currently searching and so is ignored if you happen to have stopped at almost the same instant you recieved the command. - Don On Mon, 2007-03-05 at 09:08 -0300, Eduardo Sabbatella wrote: Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas ___ 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] GTPv3
On Mon, 2007-03-05 at 09:32 -0300, Eduardo Sabbatella wrote: Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. My program Lazarus ponders on CGOS, without any help from the cgos client program, so you are right, extensions are not necessary to implement pondering. However, UCI explicity supports pondering and it makes it a no-brainer to implement. If you implement pondering you will discover that it's far from trivial, but with help from UCI (or GTP) it comes for free. This does not prevent you from implementing it internally your own way. The model UCI uses is that your program informs the controller about which move it would ponder and the controller, at the appropriate time just sends the command to start thinking on the appopriate position. Your program does not have to manage the complexity of when to abort, etc. However, it can if it wants to. So extensions to GTP do not have to support this notion of supported pondering, however there is something that cannot be faked that GTP does not support. In a commercial quality product, there is no GTP endorsed way to stop a program from thinking. Imagine playing a program at a super high level and getting impatient and wanting to see a move.Sorry, not possible with GTP. Another cool feature that is not possible is what chess people call analysis mode. You sit in front of the program with your mouse making moves and the program is following the game. It constantly updates it's opinion of the position, showing you scores, principal variations, etc. But you can make a move anytime you want for either side and the program instantly adjusts, starting a new infinite level search from the new position. It's just sitting in the background watching you place stones. It's a very cool and useful feature. Sorry, can't do this with GTP. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. I'm not confusing this issue, you can implement pondering this way but this still doesn't address the above issues. We still need to have some asyncronous commands to get cool user interfaces. I don't really care if GTP holds your hand with pondering, it's just a nice feature UCI has and it lowers the barrier for implementing pondering for newer less experienced programmers. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. I may have lost you here. Are you suggesting that we can do all of this without any asyncronous commands? - Don --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes it's mind about the move choice, it's current opinion of the score, etc. This can be implemented with polling by adding a GTP command to request information from the engine every second or two, but this feels like a hack. Thinking on the opponents time (pondering) is supported naturally by the UCI protocol. Actually, the engine doesn't need to know much about this, the controller simply tells the engine to start thinking on a given move and so the engine doesn't even know it's thinking on the opponents time. However, the engine does communicate to the controller what the ponder move is. This could ALMOST be implemented directly in GTP, except for the fact that you cannot stop the engine from searching once it begins. If I'm pondering, but the opponent doesn't play the ponder move, there is not way in GTP to say, STOP searching NOW because the move is not relevant! So GTP could not easily be used to build a high quality user interface, say for a commercial program. At least not one that had the better features, even given that you can extend the command set with additional commands. It COULD be done, just not easily. You would have to do it all with polling. You could even
Re: [computer-go] GTPv3
Yes, it's possible to do all of this with GTP as is and the addition of a few commands that stay blocking, nothing but pure GTP extensions and no asyncronous communication. I already mentioned this as polling. Instead of genmove, you send inc_genmove, which is designed to return very quickly and does only a partial search. The controller continues to send a long series of consecutive inc_genmove until the engine makes a move. And the controller can stop sending inc_genmove if it wants to abort. In fact it doesn't even need to tell the engine to abort. I think this is really rather ugly however. You are adding a LOT of extra communication and things will be sluggish if you don't send these at least 3 or 4 times per second. - Don On Mon, 2007-03-05 at 09:50 -0300, Eduardo Sabbatella wrote: Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link. you can have a couple of sub commands for get_move like: get_complete_percent, get_current_best_move, chat, etc. If the engine doesn't support realtime gtp, they will be answer after the gen_move response. one at a time. I don't know, perhaps I'm pushing too much the gtp protocol... I don't think so, but perhaps --- Nick Apperson [EMAIL PROTECTED] escribió: I think you are mostly correct. But, the problem is that GTP was designed to block on the genmove command. This is a problem because genmove is usually not quick to return. Therefore, there is no way with the current scheme to be able to issue commands while an engine is thinking. It would require a redesign perhaps using polling instead if GTP is to remain blocking. On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes it's mind about the move choice, it's current opinion of the score, etc. This can be implemented with polling by adding a GTP command to request information from the engine every second or two, but this feels like a hack. Thinking on the opponents time (pondering) is supported naturally by the UCI protocol. Actually, the engine doesn't need to know much about this, the controller simply tells the engine to start thinking on a given move and so the engine doesn't even know it's thinking on the opponents time. However, the engine does communicate to the controller what the ponder move is. This could ALMOST be implemented directly in GTP, except for the fact that you cannot stop the engine from searching once it begins. If I'm pondering, but the opponent doesn't play the ponder move, there is not way in GTP to say, STOP searching NOW because the move is not relevant! So GTP could not easily be used to build a high quality user interface, say for a commercial program. At least not one that had the better features, even given that you can extend the command set with additional commands. It COULD be done, just not easily. You would have to do it all with polling. You could even implement stop search by having a GTP command to do searching in tiny time slices. The contoller would send commands such as continue_search which must return in a fraction of second, possibly with a move.This would be truly awkward but possible. - Don
Re: [computer-go] GTPv3
I do not think that genmove should work that way. It makes more sense for you to have a genmove command and an async_endsearch command or somethinglike that. The program is allowed to keep searching as long as it doesn't receive that command. genmove doesn't need to have an async mode really. You could have async_genmove return the programs best guess at the moment, but it wouldn't be considered final until genmove returns. On 3/5/07, Don Dailey [EMAIL PROTECTED] wrote: Yes, it's possible to do all of this with GTP as is and the addition of a few commands that stay blocking, nothing but pure GTP extensions and no asyncronous communication. I already mentioned this as polling. Instead of genmove, you send inc_genmove, which is designed to return very quickly and does only a partial search. The controller continues to send a long series of consecutive inc_genmove until the engine makes a move. And the controller can stop sending inc_genmove if it wants to abort. In fact it doesn't even need to tell the engine to abort. I think this is really rather ugly however. You are adding a LOT of extra communication and things will be sluggish if you don't send these at least 3 or 4 times per second. - Don On Mon, 2007-03-05 at 09:50 -0300, Eduardo Sabbatella wrote: Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link. you can have a couple of sub commands for get_move like: get_complete_percent, get_current_best_move, chat, etc. If the engine doesn't support realtime gtp, they will be answer after the gen_move response. one at a time. I don't know, perhaps I'm pushing too much the gtp protocol... I don't think so, but perhaps --- Nick Apperson [EMAIL PROTECTED] escribió: I think you are mostly correct. But, the problem is that GTP was designed to block on the genmove command. This is a problem because genmove is usually not quick to return. Therefore, there is no way with the current scheme to be able to issue commands while an engine is thinking. It would require a redesign perhaps using polling instead if GTP is to remain blocking. On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes it's mind about the move choice, it's current opinion of the score, etc. This can be implemented with polling by adding a GTP command to request information from the engine every second or two, but this feels like a hack. Thinking on the opponents time (pondering) is supported naturally by the UCI protocol. Actually, the engine doesn't need to know much about this, the controller simply tells the engine to start thinking on a given move and so the engine doesn't even know it's thinking on the opponents time. However, the engine does communicate to the controller what the ponder move is. This could ALMOST be implemented directly in GTP, except for the fact that you cannot stop the engine from searching once it begins. If I'm pondering, but the opponent doesn't play the ponder move, there is not way in GTP to say, STOP searching NOW because the move is not relevant! So GTP could not easily be used to build a high quality user interface, say for a commercial program. At least not one that had the better features, even given that you can extend the command set
Re: [computer-go] GTPv3
I don't think it should work that way either. I was just suggesting that it's possible to do everything required without any anynchronous changes to GTP, but I certainly don't recommend this method. - Don On Mon, 2007-03-05 at 10:07 -0600, Nick Apperson wrote: I do not think that genmove should work that way. It makes more sense for you to have a genmove command and an async_endsearch command or somethinglike that. The program is allowed to keep searching as long as it doesn't receive that command. genmove doesn't need to have an async mode really. You could have async_genmove return the programs best guess at the moment, but it wouldn't be considered final until genmove returns. On 3/5/07, Don Dailey [EMAIL PROTECTED] wrote: Yes, it's possible to do all of this with GTP as is and the addition of a few commands that stay blocking, nothing but pure GTP extensions and no asyncronous communication. I already mentioned this as polling. Instead of genmove, you send inc_genmove, which is designed to return very quickly and does only a partial search. The controller continues to send a long series of consecutive inc_genmove until the engine makes a move. And the controller can stop sending inc_genmove if it wants to abort. In fact it doesn't even need to tell the engine to abort. I think this is really rather ugly however. You are adding a LOT of extra communication and things will be sluggish if you don't send these at least 3 or 4 times per second. - Don On Mon, 2007-03-05 at 09:50 -0300, Eduardo Sabbatella wrote: Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link. you can have a couple of sub commands for get_move like: get_complete_percent, get_current_best_move, chat, etc. If the engine doesn't support realtime gtp, they will be answer after the gen_move response. one at a time. I don't know, perhaps I'm pushing too much the gtp protocol... I don't think so, but perhaps --- Nick Apperson [EMAIL PROTECTED] escribió: I think you are mostly correct. But, the problem is that GTP was designed to block on the genmove command. This is a problem because genmove is usually not quick to return. Therefore, there is no way with the current scheme to be able to issue commands while an engine is thinking. It would require a redesign perhaps using polling instead if GTP is to remain blocking. On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering. I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey [EMAIL PROTECTED] escribió: I like GTP and I champion it.However, there are some weaknesses and they are not easily fixed without a major paridigm change. 1. There is no way to STOP a program from thinking. This is needed for a high quality user interface. 2. There is no natuaral way to get useful information from the go program, such as it's thinking process. A quality user interface should be able to show the user the thinking process of the program, when it changes
Re: [computer-go] How did MoGo do it?
On Mon, 2007-03-05 at 11:58 -0300, Eduardo Sabbatella wrote: Also sometimes it scales but not lineal, thats an issue to. A big one. Like raw MC, you can get a very good move with less than 70k simulations, to get a really good move perhaps you need 400 billons. I remember there is a paper about this with a 'oracle' MC engine and they used it to compare to different mc implementations. MC oracle was a MC engine running like 100 billon simulations for every move. But this doesn't scale to perfect play. Without the tree search beneath it, it doesn't matter how many trillions of simulations you do, even trivial errors like incorrect auto-atari's cannot be solved because it might statistically be the very best move against random play. - Don --- Don Dailey [EMAIL PROTECTED] escribió: Sylvain, What you say is no surpise to me about the constraints. I knew that if you improved things, you would eventually have to improve or reduce the constraints. The simple question I always ask about a feature is whether the idea is infinitely scalable. Some idea are very good in the short term, but in the long term form a barrier to improvement. Of course that doesn't mean the idea shouldn't be used because it might be helping you. But at some point you know your program will out-grow the idea and then it will be holding you back. A good example of this is piece square tables in computer chess. It was a wonderful way to add a lot of knowledge to a chess program without slowing it down any. It's based on the idea of looking at the starting position, making a lot of stategic decisions before you even begin searching (by filling the table with values) and then doing the search. This idea has serious limitation when you search incredibly deep, but really worked well in the days when programs could not search deeply. I think some programs still use this today but to a lesser extent - they have adjusted accordingly with much more dynamic evaluation. I have this theory that if something isn't properly scalable, then you are probably doing it wrong - at least in an idealistic sense. From a practical standpoint I have no trouble doing these non-scalable things if there is no obvious scalable solution that can give me the same short-term improvement. AnchorMan is a clear example of this non-scalable approach. A hackery of non-scalable patches to try to stop it from playing the ugliest of moves! - Don On Mon, 2007-03-05 at 10:52 +0100, Sylvain Gelly wrote: Hello Peter, Hello Don, Hello all, It is true that I have been mainly working to improve the level of MoGo in 19x19. It turned out in my experiments, that improving its level in 9x9 with very little simulations was significant for the level in 19x19, so it is one reason why the limited version of MoGo are running on cgos. So even if the goal was 19x19 improvements, the improvements appeared in all boardsizes. Our first approach to 19x19 was, as you say Don, to constrain the board (as explained in our paper), and it brought improvements. However, now it is quite the contrary what is happening, each improvement allows to remove constrains on 19x19, and making it play as if it was a 9x9 board (I mean in the parameters). As you may have noticed for example, MoGo is not playing locally anymore on 19x19 (which gives it an ugly style :-)). The number of simulations done in this tournament was from 10k to 50k per move, depending on the context and the move number (simple time management stopping early the thinking if one move is clearly better than the others). For all the details on the improvements, we submitted a paper, and I am writing them in my thesis, so you will all know, just wait for them to be written :-/. I still strongly believe in the future of MC even in 19x19. Bye, Sylvain 2007/3/5, Don Dailey [EMAIL PROTECTED]: I'm pretty sure I read that the MoGo team is shifting their efforts towards 19x19 GO. There are lot's of possibilites for research, but Mogo already does things to constrain the board on 19x19, they are probably just refining this stuff. - Don On Sun, 2007-03-04 at 19:58 -0800, Peter Drake wrote: Congratulations to MoGo on winning the KGS tournament held earlier today: http://www.gokgs.com/tournEntrants.jsp?sort=sid=270 Even under borderline blitz conditions (18 minutes sudden death for 19x19), MoGo managed to beat conventional programs like GNU Go. (ManyFaces apparently had some connection/restarting glitch, so its performance may not be representative.) Of course, MoGo also beat all the other MC/UCT programs. How
[computer-go] March KGS bot tournament results
Congratulations to MoGo for winning both divisions, with a total of 12 wins and no losses, despite the fast time limits and large boards! I must confess I did not expect this. It is a most impressive result. My report is at http://www.weddslist.com/kgs/past/24/index.html. I fear it probably contains as many errors as usual. Nick -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Go hardware?
Maybe this would make a good Go card: http://gizmodo.com/gadgets/peripherals/nvidia-ships-128core-graphics-cards-for-highend-film-editors-graphics-pros-apple-excited-241478.php ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Don Dailey wrote: On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote: On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote: And you CAN compare GTP directly to UCI because both are designed for the same purpose and both are simple text based protocols and the similarities are much greater than the differences. GTP has many purposes. One of them is to sit betwene an engine and an UI, but that is not the only one. It is also used for test scripts to validate engines, and to debug them. So, what even asynchronous extensions you are adding to GTP, please keep the simple synchronous mode still available, for it has many uses too! If I were designing the asynchronous extentions I was mandate that the core doesn't change - that you can continue to use GTP as is without any suprises. I'm entering this discussion a bit late, but what about the following idea? Perhaps we could start from scratch and create the protocol we want with no compromises based perhaps on an async event message model - a model everyone probably is quite familiar with. It could move beyond ASCII messages on stdout and be designed for extensibility. Add all the common features we are looking for to really make a modern, robust and complete system. Since something like this would be a superset of GTP, a reference implementation of the new protocol could also include a proxy implementation of GTP using the new protocol. This would allow the best of both worlds - programs can continue to use GTP if they wanted, operating in a more constrained context than programs that implement and use the new protocol. Years into the future we won't have the baggage of GTP still as likely all programs would eventually move to the new standard. Just a thought... -Matt ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Mon, 2007-03-05 at 20:00 -0600, Matt Gokey wrote: I'm entering this discussion a bit late, but what about the following idea? Perhaps we could start from scratch and create the protocol we want with no compromises based perhaps on an async event message model - a model everyone probably is quite familiar with. It could move beyond ASCII messages on stdout and be designed for extensibility. Add all the common features we are looking for to really make a modern, robust and complete system. Since something like this would be a superset of GTP, a reference implementation of the new protocol could also include a proxy implementation of GTP using the new protocol. This would allow the best of both worlds - programs can continue to use GTP if they wanted, operating in a more constrained context than programs that implement and use the new protocol. Years into the future we won't have the baggage of GTP still as likely all programs would eventually move to the new standard. Just a thought... -Matt Hi Matt, There are two potential problems with this. 1. If you get too far away from the current GTP protocol, it won't be accepted. 2. In either case, if you push for the new protocol you will hurt the computer go community. I don't pretend to know how likely these scenario's are, but it's my fear. If I WERE to do something from scratch, I would start with UCI from the chess world and make only minor changes to make it more appropriate for GO. Not because I'm also a chess programmer, but because it's a fully tested protocol and because it rocks. I would point out that the chess world has 2 main protocols, one that wasn't really planned but evolved from the xboard/winboard projects. This is still a problem - if you get a chess engine and a chess user-interface you have to make sure they are compatible, because some engines use only one or the other and some interfaces use one or the other although most good interfaces try to work with both. But I don't really want this to happen with computer go. (Of course there is GMP, but it's not a serious contender for a quality user interface.) I also hate to break away from the gnu project - it's their good work that has set the standard for GTP.I believe if they solve this problem with some kind of asynchronous protocol and build it into gnugo, it will be accepted. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
