Once the opponent chooses a move I will descend into that path and throw away the rest of the tree. This is basically the same as when I make a normal move. The only real coding I still need to do is add the capabilities to the GTP interface. I could overlooking something though... -- Francois van Niekerk Email: [email protected] | Twitter: @francoisvn Cell: +2784 0350 214 | Website: http://leafcloud.com
On Tue, Sep 14, 2010 at 1:13 PM, Stefan Kaitschick < [email protected]> wrote: > What do you plan to do once the opponent actually decides on a move? > You either have to throw away the non-relevant results or supply twice the > memory in the worst case. > Depending on the implementation, discarding partial results might not be so > easy. > But you should ask the successful implententors of pondering for advice. > > Stefan > > Am 14.09.2010 11:44, schrieb Francois van Niekerk: > > I assume MCTS. I am yet to implement pondering (thinking in the opponent's > time), but I was going to just continue searching in my tree during the > opponent's time. No particular move is picked, but the most likely moves by > the opponent will automatically receive more focus due to the algorithm. > This seems better to me (and most efficient possible). Is this not the > normal way? > > This would obviously not give time for the dynamic komi estimation you > suggest, but intuitively this seems like it will yield the best results (in > even games). > -- > Francois van Niekerk > Email: [email protected] | Twitter: @francoisvn > Cell: +2784 0350 214 | Website: http://leafcloud.com > > > On Tue, Sep 14, 2010 at 11:28 AM, Stefan Kaitschick < > [email protected]> wrote: > >> The usual way to use the opponents time, if it is used at all, is to >> guess the opponents move, and do a normal search on that presumption. >> If the guess was correct, then the search results can be used, otherwise >> they are thrown away. >> This is probably the most reasonable way, but ofcourse the effectiveness >> is not so great. >> Getting back to the the dreaded topic of dynamic komi, I would like to >> suggest an alternate way of using this time: >> Do a normal move search at several different komi levels, each with a >> fraction of the normal number of positions. >> It's not about finding the best move, only about estimating the winrate at >> different komi levels. >> This komi vs winrate profile could then be used to determine komi for the >> next search. >> Basically adjust the komi to the largest value that avoids a significant >> drop from the winrate at regular komi. >> The standard approach probably goes for a certain winrate that must be >> maintained, but that way it's impossible to say how much additional risk is >> actually beeing taken. >> >> Stefan >> _______________________________________________ >> Computer-go mailing list >> [email protected] >> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >> > > > _______________________________________________ > Computer-go mailing > [email protected]http://dvandva.org/cgi-bin/mailman/listinfo/computer-go > > > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
