Hello,
the topic "matrix completion" has become famous, in
particular after a competition organized by the
NetFlix company. NetFlix has many customers and (not so)
many films. They want to generate personalized
recommendations for their customers ("you might also like
movie X").
Transfer to
I haven't read how programs 'catalog' play under various categories,
like for http://gostyle.j2m.cz/
but only if the acquisition of some features is easier than others,
giving an incomplete view of the
opponents, would a technique like matrix completion be necessary, no?
If from just 2-5 games
Hi,
My experience is the same: My CNN was a very poor judge of life and
death. Part of the problem is that I couldn't get Pachi to behave
exactly the way I wanted (play to maximize score; play to the bitter
end, assuming everything left after two passes is considered alive). But
perhaps there
I understand that using games from humans to learn about life and death
introduces all sorts of biases. That's why I tried to use games from an
engine instead.
In their standard configuration, MCTS engines will sometimes let lots of
groups die after they know the game is hopeless, or if they have
Well my point is more in the direction to get a good live-and-death
solver, maybe completely independent of the game as a whole. Just train
a DNN on some life-and-death collections with solutions, where all of
the usual tricks are applied. I think this has the potential to get
similar if not
Hi!
On Fri, Jan 15, 2016 at 04:54:18PM -0500, Álvaro Begué wrote:
> In their standard configuration, MCTS engines will sometimes let lots of
> groups die after they know the game is hopeless, or if they have a large
> advantage and they still see a guaranteed victory after the group dies.
>
On Fri, Jan 15, 2016 at 5:14 PM, Petr Baudis wrote:
> Two ideas re Pachi:
>
> (i) In uct/uct.c maximize_score section, try changing the
> max_losing_komi from 30 to, say, 300.
>
> (ii) Try to work out that if Pachi decides it's losing, the gameplay
> is switched over to GNUGo
On 1/15/16 2:07 PM, Michael Sué wrote:
Well my point is more in the direction to get a good live-and-death
solver, maybe completely independent of the game as a whole. Just train
a DNN on some life-and-death collections with solutions, where all of
the usual tricks are applied. I think this has
To me (a weak Go player), the priorities on parameter changes from Fuseki,
to when counting score on the board becomes relatively accurate, to Yose /
end-game. So I've been using different parameters for different stages in
a game for my non-MCTS non-DCNN traditional-logic engine for a long time,