27;m way off course,
I'm an amateur! 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
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
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
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 g
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 l
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 q
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 l
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-m
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 aga
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
>
10 matches
Mail list logo
