Unknown wrote:
BTW: once you choose the /8 gain by implementing canonicalization,
you'll probably want to implement /2 color-swaps, too. (but this will
only be profitable for libraries, not for 'history' such as in Don's
case.)
The /2 with color-swaps would work fine with librarys that don't
On Fri, 2007-02-09 at 13:19 +0100, Ephrim Khong wrote:
The /2 with color-swaps would work fine with librarys that don't store
the whole gamestate, but I doubt it's worth implementing it in
fuseki-librarys: Since there are usually no or very few captures
during
the fuseki, the player whos turn
Quoting Don Dailey [EMAIL PROTECTED]:
Doing 8 searches is time-consuming, but I really prefer a book
that has a LOT of variety.
This is also one reason I now hand edit my book. Every time I correct a
bad move
there are often several ways of playing that I cannot tell which is better or
Magnus Persson wrote:
This is not a problem for scalability for MC/UCT. It just
means that a program ..
You are right. I didn't mean it is not scalable, of course
it is. What I mean is complexity is not, as one could
expect, about ~boardsize^4. (The square of legal moves
times the square of
On Thu, 2007-02-08 at 15:55 -0500, Don Dailey wrote:
The children of one parent almost certainly will have different 64 bit
keys than the children of the other parent.
Not if the parents collide.
(apart from symmetry/canonical considerations):
if H(A)==H(B),
then after applying move 'm'
--
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
difference which is the canonical key, so we just declare the first
one that we find to be the canonical.
tranforms as the cannonical key. In most cases 8 positions will
IIRC, choosing the smallest may cause some unwanted effects. Not sure...
It's not quite as good as using 64 bits free and clear because there is
compression towards the lower bits.
i must be missing something here -- the
On Thu, 2007-02-08 at 15:58 -0800, steve uurtamo wrote:
tranforms as the cannonical key. In most cases 8 positions will
IIRC, choosing the smallest may cause some unwanted effects. Not sure...
It's not quite as good as using 64 bits free and clear because there is
compression
light is always a good adagium, see David Fotlands hilarious
compression of a joseki library into 12 bits/move, IIRC ;-)
More like 10 bits per move to store the joseki DAG, moves, pointers, and
good/bad/trick flags. I would never do anything like that now, but back
then the entire go
On Thu, 2007-02-08 at 15:36 -0800, David Doshay wrote:
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
difference which is the canonical key, so we
It depends. (though travel light is always a good adagium,
see David Fotlands hilarious compression of a joseki library
into 12 bits/move, IIRC ;-)
this reminds me of an old-school optimized piece of scrabble-playing
code. there was a routine that would take an ascii list of words and
create
On Thu, 2007-02-08 at 15:58 -0800, steve uurtamo wrote:
tranforms as the cannonical key. In most cases 8 positions will
IIRC, choosing the smallest may cause some unwanted effects. Not sure...
It's not quite as good as using 64 bits free and clear because there is
compression
On Thu, 2007-02-08 at 18:43 -0800, steve uurtamo wrote:
It depends. (though travel light is always a good adagium,
see David Fotlands hilarious compression of a joseki library
into 12 bits/move, IIRC ;-)
this reminds me of an old-school optimized piece of scrabble-playing
code. there
On 8, Feb 2007, at 6:42 PM, Don Dailey wrote:
On Thu, 2007-02-08 at 15:36 -0800, David Doshay wrote:
We had this same problem and wasted a huge amount of time and
energy on trying to determine the right canonical key. I felt both
proud and stupid when I realized: it really does not make any
Matt Gokey wrote:
But what are some of the reasons MC is not even better?
1-Since MC engines don't deal with tactics directly, they're not likely
going to play tactical sequences well for low liberty strings, securing
eye space, cutting and connecting, ko fights, or ladders, etc.
2-Also because
Jacques Basaldúa wrote:
Very good analysis and I would like to contribute a 4th reason:
As Luke Gustafson pointed out, we have to contemplate the simulation
as a _stochastic process_. We want to determine the conditional
probability of a win given a particular move is made. And that depends
on
Two qick comments:
Quoting Matt Gokey [EMAIL PROTECTED]:
Jacques Basaldúa wrote:
Very good analysis and I would like to contribute a 4th reason:
against scalability of global search MC/UCT. If the simulation is
500 moves long (Chinese rules with recaptures, etc.) the observed
variance at an
Magnus Persson wrote:
Quoting Matt Gokey [EMAIL PROTECTED]:
(snip)
Good point. This leads to another thought that I have been wondering
about. That is I question whether using more time to search more
simulations in the opening is the best approach. For the opening,
selecting
On Wed, 2007-02-07 at 14:10 -0600, Matt Gokey wrote:
I was wondering if anyone was combining an opening library with MC/UCT
by running a large number of the simulations and storing the results.
This seems like a pretty natural extension to save simulation time in
the opening.
This is not
On Wed, 2007-02-07 at 16:17 -0500, Don Dailey wrote:
I have a hash funciton that creates a 64 bit cannonical hash of
the position. The same hash is produced after a rotation for
example. A book entry is a record with 3 fields, a priority
value (how many times the deep search selected this
Quoting Matt Gokey [EMAIL PROTECTED]:
Magnus Persson wrote:
Quoting Matt Gokey [EMAIL PROTECTED]:
I was wondering if anyone was combining an opening library with MC/UCT
by running a large number of the simulations and storing the results.
This seems like a pretty natural extension to save
On Wed, 2007-02-07 at 16:28 -0500, Don Dailey wrote:
On Wed, 2007-02-07 at 16:17 -0500, Don Dailey wrote:
I have a hash funciton that creates a 64 bit cannonical hash of
the position. The same hash is produced after a rotation for
Most people do incremental hashing, which is cheaper even
On 2/7/07, Unknown [EMAIL PROTECTED] wrote:
to binary search the file on the parent position key,
collect all of these records together (making sure there is a
legal move which leads to the cannonical response key) and then
You are not clear here.
Is there only a one-move-step between key
On Thu, 2007-02-08 at 01:00 +0100, Unknown wrote:
On Wed, 2007-02-07 at 16:28 -0500, Don Dailey wrote:
On Wed, 2007-02-07 at 16:17 -0500, Don Dailey wrote:
I have a hash funciton that creates a 64 bit cannonical hash of
the position. The same hash is produced after a rotation for
After looking at your message I'm not sure you understand how
I set this up.
On Thu, 2007-02-08 at 01:00 +0100, Unknown wrote:
to binary search the file on the parent position key,
collect all of these records together (making sure there is a
legal move which leads to the cannonical
It seems to me, the fundamental reason MC go (regardless of details)
works as it does is because it is the only search method (at least that
I am aware of) that has found a way to manage the evaluation problem.
Evaluation is not as problematic because MC goes to the bitter end
where the status is
26 matches
Mail list logo
