No, simple radiation is not the best, although some programs (including mine)
started with something like this. I think the best approach was Reiss' Go4++,
where territory was modelled using connectivity. If a new stone can be
connected to a living group of the same color, then this point can'
Yes, in the old engine, I roll everything up into a single number, with a
resolution of 1/100th of a point (only so the total score would fit in a 16 bit
integer on the 16 bit machine I used for development in 1982).
I would say rather, that expert systems are dead in Go because many smart an
I never tried to optimize stopping, so my stopping rule is very conservative.
Many Faces stops at twice the number of points on the board, or if the mercy
rule triggers. The mercy rule requires one side to have many more stones on
the board than the other (at least 1/3 of the number of points
Aya stops playout at 81 moves in 9x9, and 361 moves in 19x19 from
playout start position. It does not change strength much.
In stop position, Aya counts one liberty string is dead.
19x19, against GNU Go (2000playout/move), 1000 games
Winratestop moves
0.461 321
0.460 341
0.46
"I agree that group strength can't be a single number. That's why I
classify groups instead. Each classification is treated differently when
estimating territory, when generating candidate moves, etc. The territory
counts depend on the strength of the nearby groups."
this touches on an issue wh
Steenvreter stops its playouts when it detects a proven win or loss. The
evaluation function it uses is an improved version of what I made to solve
the small boards. I once tried adding the mercy rule, but it did not
improve the program.
Erik
On Wed, Sep 9, 2015 at 5:46 PM, Peter Drake wrote:
Hi list,
thank you for your answers! I tried answering with a picture but it got blocked,
so if you're interested here it is:
https://dl.dropboxusercontent.com/u/3126408/IMG_9456.jpg
Gonçalo> I am using GnuGo to manage the board structure and legality of moves.
But I note that displaying the kos
I don't know of an article, but unless your ending detection is VERY fast,
it's better to just finish the playout.
One possibility is a "mercy threshold": if one player's stone count (which
you update incrementally) far exceeds the other, declare the player with
more stones the winner. The relevan
On 09.09.2015 16:45, Jim O'Flaherty wrote:
I'm not convinced that it's reducible
I am convinced it is,...
[...] to [...] a [...] set of principles
...where the principles need some dynamic input, such as reading, when
necessary.
I don't think it can currently be done for a static Go pos
Does anyone know of a good article on ending a MCTS playout early,
outcome estimation, the quality of interrupted outcomes, and so on?
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
I'm not convinced that it's reducible (as in reductionism) to get to a
rational (i.e. highly influenced by deterministic math) set of principles
to describe Go (which appears to be a precondition to getting it mapped
into your expert system). In fact, I don't think it can currently be done
for a st
On 09.09.2015 09:53, Petri Pitkanen wrote:
Too many contradicting heurestics
The mid-term problem is not mutual contradiction of heuristics because
their careful study can remove the contradictions and establish a
hierarchy of principles. Only the problem of great number of principles
to be
David said "estimate final score" which implies that all relevant things
are factored in, merely the unit of estimation is territory. Just like in
chess there are several things factored in - other than material - and all
are estimated as pawns.
I guess expert systems really are a dead end in Go
On 09.09.2015 07:42, David Fotland wrote:
I classify groups instead. Each classification is treated differently when
estimating territory, when generating candidate moves, etc.
This is reasonable.
The territory counts depend on the strength of the nearby groups.
Whether this is good depen
14 matches
Mail list logo