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
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
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
d
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.
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
>
> 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
cre
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 w
> 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 pro
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
>
> > > 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
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.
On Fri, 2007-02-09 at 00:18 +0100, Unknown wrote:
> 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
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'
-
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 o
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
wor
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
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
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 ke
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
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 sav
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
On Wed, 7 Feb 2007, Matt Gokey wrote:
Magnus Persson wrote:
Quoting Matt Gokey <[EMAIL PROTECTED]>:
is important to get a won position as early as possible. The longer it
thinks the better it plays. In the opening it always critical to find the
best move - but later on games are often either
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
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 reasonab
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
> It would be interesting for someone with a decent MC player to do an
> experiment like this with one version concentrating highest number of
> simulations in the opening and one concentrating in the middle game, but
> otherwise equal and see which version wins more often.
ooh, now this is exc
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
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
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
29 matches
Mail list logo
