A long time ago I thought of how to organize what to prune The Right Way
(tm). I initially thought about it in the context of computer chess, but I
think it is even more relevant for computer go. Instead of doing global
search where you say a node will be considered a leaf if it is n moves away
On Dec 5, 2007 9:33 AM, Erik van der Werf [EMAIL PROTECTED] wrote:
Look for Realization Probability Search.
Oh, thanks! I knew it was too natural to be original. Well, I actually
thought about it around 1998, so it might have been new back then.
This is very close to what I was saying:
On Dec 5, 2007 1:35 PM, Don Dailey [EMAIL PROTECTED] wrote:
Yes, I think there is a lot to this.Searching by depth is rather
arbitrary.
I think this basic idea is called realization probabilities and I
thought of doing it with the Bradley Terry model.
It also occurred to me that if a
On Dec 5, 2007 5:01 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 5, 2007 9:33 AM, Erik van der Werf [EMAIL PROTECTED] wrote:
Look for Realization Probability Search.
Oh, thanks! I knew it was too natural to be original. Well, I actually
thought about it around 1998, so it might have
On Dec 5, 2007 11:33 AM, Erik van der Werf [EMAIL PROTECTED] wrote:
On Dec 5, 2007 5:01 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 5, 2007 9:33 AM, Erik van der Werf [EMAIL PROTECTED]
wrote:
Look for Realization Probability Search.
Oh, thanks! I knew it was too natural to be
On Dec 4, 2007 1:42 AM, Petri Pitkanen [EMAIL PROTECTED] wrote:
There is something that the latest Monte Carlo programs have in common
with the best chess programs - and seems to be the right way to
structure a game tree search.Your selectivity should be
progressive. In order to
Relatively speaking chess eval of adding piece values together and
doing nothing else is far closer to optimal evaluation function that
what is currently available in Go.
A GOOD go evaluation function probably needs to incorporate lookahead...
Through most of the game, the difference between a
David Doshay wrote:
On 22, Nov 2007, at 9:35 AM, Don Dailey wrote:
This is one of many things in life that people refuse to believe -
regardless of the evidence. ...
Instead, people focused on highly selective searches. In order to
play strong it was clear that computers would have to
Yes, in its present instantiation, SlugGo is inadmissibly selective.
In this case, we clearly see that after some small number, more
plies of global search result in worse play.
I do not have any expectation of perfect play, only improvement
over the present state of things.
Cheers,
David
On
There is something that the latest Monte Carlo programs have in common
with the best chess programs - and seems to be the right way to
structure a game tree search.Your selectivity should be
progressive. In order to do this correctly you must re-visit nodes
many times. Chess programs
Instead of responding individually, I would like to address a myth in
one message.The myth is that any kind of global search, whether it
be alpha/beta, or the currently explored best first search methods is a
foolish approach and that there is a some kind of constant time elegant
algorithm
it's in EXPTIME, with boardsize as the parameter.
s.
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, November 22, 2007 12:35:37 PM
Subject: [computer-go] The global search myth
Instead of responding individually, I
it's PSPACE-hard and EXPTIME-complete, although this is dependent upon the
rules involved. i think that superko changes things a tiny bit. in any case,
it's
brutally difficult as the boardsize increases.
JM Robson, The Complexity of Go. In Information Processing; proceedings of
IFIP
Subject: Re: [computer-go] The global search myth
it's PSPACE-hard and EXPTIME-complete, although this is dependent upon
the
rules involved. i think that superko changes things a tiny bit. in
any case, it's
brutally difficult as the boardsize increases.
JM Robson, The Complexity of Go
Don Dailey wrote:
Back then the ELO curve was not understood. The basic formula was
eventually found that 1 ply added 250 ELO rating points to a program.
[...]
At some point, some incredibly foolish programmers at Northwestern
University built a program and decided that it was too hard to do
Can you elaborate on the relation between the 'ELO curve'
and the
improved evaluation functions? Is it that if you took this original
'brute force' program and ran it on current hardware, it would gain 250
rating points per ply, and the improved evaluation functions allow
modern programs to
16 matches
Mail list logo
