[Computer-go] Why do Facebook use DNN next-move predictors? Shouldn't they use next-move generators?

ateur! sorry for wasting your time if so!), then rather than training a move predictor, they should use the adversarial methods which are also in the wind now to train a generative model. -- Harald Korneliussen ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go

[computer-go] Selling programs on Linux

Gian-Carlo Pascutto Unfortunately I don't know how to sell support for my Go program, but I am open to ideas. Well, since you ask, there is one neat way you can sell your program on Linux in an open source manner: Offer a so-called assurance contract, such as the ones on fundable.org. The basic

[computer-go] The odd 13x13 graph

Don Dailey wrote: It's also interesting how the graph up to level 11 seems to form 2 very straight lines, almost as if they were connected at an angle. This must be a by-product of how we started the test. We played only the first 4 levels as we were testing the system and that is where the

[computer-go] Bent four in the corner was:Scalability problem of play-out policies

Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a

[computer-go] The intelligence can of worms reopened

In the thread On average how many board updates/sec can top Go programs do these days? mingwu said of the way MC/UCT programs work that he'd hardly call it intelligent. I've thought (and argued elsewhere) that the MC/UCT approach is fundamentally more intelligent, in the sense of working more like

[computer-go] Re: language efficiency

Some thinking out loud here on the topic of languages and efficiency: I'd like to know how well MoGo would have played if you let it think for a week for every move. Only it seems to me that is not possible, because I don't think MoGo will run for a week without crashing. Crazystone also crashes

Re: [computer-go] Lisp time

Don Dailey wrote: By the way, I am no fan of C. I don't like C and have tried some of the languages on your list of languages that are supposedly faster than C. I think you must be getting your information from the web pages for those languages. As a general rule any reasonably fast

Re: [computer-go] low-hanging fruit - yose

Mark Boon wrote: Let me therefore change the discussion a bit to see if this will make things more clear. Consider a chess-playing program with an unorthodox search method. When playing a human after while it announces check-mate in thirty-four moves. Yet the human can clearly see it's check-mate

Re: [computer-go] How does MC do with ladders?

Raymond Wold wrote: I can code an algorithm that evaluates simple ladders correctly. I'll repeat that. I can code a program that reads ladders better than a pure MC program without knowledge of ladders. I can beat it. Human knowledge programmed into a computer that does that one thing, that

Re: [computer-go] How does MC do with ladders?

Wed, 12 Dec 2007 07:14:48 -0800 (PST) terry mcintyre wrote: Heading back to the central idea, of tuning the predicted winning rates and evaluations: it might be useful to examine lost games, look for divergence between expectations and reality, repair the predictor, and test the new predictor