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 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 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 > > > [email protected] > > > > > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > > _______________________________________________ > > computer-go mailing list > > [email protected] > > > 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 [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
