I have also advocated this, comparing it to quiesence search in chess.
I still think this would be effective if done well.
Actually I think it is actually critical for high level play.
Because permutating between multiple semeais in all parts of the tree
will always kill any amount of computing power available.
There are problems that go beyond spotting local semeais and playing the
correct moves.
You artificially remove ko threats, and you also change ladders.
So in some situations the preliminary cleanup would need to be partially
undone - very messy.
Perhaps these preliminary moves would need a different status, something
like "as good as played"
That is what humans do, although I admit that that has been a poor
indicator for mc programming.
Stefan
Am 13.01.2011 12:52, schrieb Kahn Jonas:
By the way, has anybody tried the most basic way to settle semeais in
playouts? I mean:
* Spot semeais (not basic at all, but probably necessary for almost all
approaches).
* Play all the moves in the semeai before going to usual playouts.
Of course this would primarily be for semeais with one-tempo difference.
This gives a systematic advantage to the player who wins the
semeai. But I don't know if it would have that much influence on the
playouts. After all, they do not take ko threats into account.
Jonas, for the barbaric why-don't-you-use-this-way that really does not
work association.
Hi Petr and Jean-loup,
I think Erica might drop to 2d if using the same time setting of Pachi2
(over 20mins SD).
The semeai in the bottom-left of this game is very interesting:
http://files.gokgs.com/games/2011/1/13/pachi2-BOThater36.sgf
I believe, we must solve this kind of long-semeai to make our programs
reach high dan.
Aja
----- Original Message -----
From: Jean-loup Gailly
To: [email protected]
Sent: Thursday, January 13, 2011 7:20 PM
Subject: Re: [Computer-go] pachi2
Here is some preliminary information on the distributed version of
pachi.
Petr (pasky) and I will publish all the details later, this is just
to give
you an idea of what we are doing. Pasky is the main author of pachi
and
wrote most of the single machine code. I wrote the distributed code
and
some other improvements.
All the code, including the distributed code, is GPL and available
at
http://repo.or.cz/w/pachi.git/
The distributed pachi uses simple tcp/ip sockets, not MPI. This
makes it
portable to many environments. A master process receives stats
updates
regularly from all the slaves and distributes the aggregated
updates back
to all slaves. The master-slave protocol is specific to pachi but
it is
rather simple. It is fault tolerant: if a slave dies, the master
will send
again the whole game to the new slave that will replace it. If the
master
dies, I ignore the current game and restart a new one when doing
test
runs. If the master dies when running for KGS, I kill the kgsGtp
program
and start a new one; KGS then sends again the partial game and we
continue
from there.
I measured scalability both on a single machine and in distributed
mode. All the details will be published, but here is a summary. In
single
machine mode, doubling the number of cores gains roughly 100 elo or
one
stone. (I measured one stone to be approximately 100 elo). This is
true up
to the number of cores I can test (20 per machine, other cores are
reserved
for the OS and other apps).
In distributed mode doubling the number of machines initially gains
approximately 50 elo (half a stone) up to 8 machines. Above this
we
quickly hit a scalability limit and the best result so far is with
64
machines; this is the configuration used for the KGS tournament
(starting
at round 4) and on KGS right now. 128 machines are currently much
worse
than 64.
Preliminary analysis of the lost games shows that the current code
has inherent scalability limits because the playouts are biased.
When the playouts incorrectly judge the life status of a group,
the results will be bad no matter how many cores and machines
work on it. We are of course working on this to eliminate these
scalability limits.
Pachi has benefited enormously from ideas published on the
computer-go
mailing list and in many papers. By making its source completely
open we
hope to encourage further progress in this area.
Petr and Jean-loup
________________________________________________________________________________
_______________________________________________
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
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
