The second explanation was no clearer to me. I'll try to criticize in
more detail:
1. Uniform playouts, as used in practice, are not really uniform over
all legal go moves. Generally, pass moves are excluded until
necessary, and moves that fill eyelike points are excluded. So, I
assume that
On 4/8/07, Don Dailey [EMAIL PROTECTED] wrote:
These programs, in theory, will play perfect GO given
enough time.
... and space. I doubt that your current programs would be capable of
storing a large enough game tree to actually converge to the
alpha-beta value. So in practice, it really
On Mon, 2007-04-09 at 05:30 -0400, Weston Markham wrote:
On 4/8/07, Don Dailey [EMAIL PROTECTED] wrote:
These programs, in theory, will play perfect GO given
enough time.
... and space. I doubt that your current programs would be capable of
storing a large enough game tree to actually
Don, here is a question. Your curves plotted the playing level vs the computer
speed. By computer speed you mean the number of MC simulations per node with
all other factors fixed. Is this correct? If it is, it's legitimate for people
to speculate that the curve could level off beyond some
On Mon, 2007-04-09 at 14:46 +0100, Tom Cooper wrote:
Perhaps it would be possible to infer how the lines would look as
perfect play was approached from what the curves looked like
for a smaller board size.
I thought that too, but the studies on 5x5 and 7x7 break down
very quickly. The
I think following is a way to reduce the noise in alpha-beta search. Instead of
using the evaluation values, use the cummulative evaluation values. That is the
sum of the evaluation values of each node of the playing path under examination.
Daniel Liu
On Sun, Apr 08, 2007 at 10:18:10AM +0200, Chrilly wrote:
Paper 1 in the list below states:
Numbers were originally implemented in Lisp I as a list of atoms.
and the Lisp 1.5 manual states: Arithmetic in Lisp 1.5 is new
Could you give an example how the number 3 was implemented in Lisp-1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 9, 2007, at 19:36 , Nick Wedd wrote:
I have written a short report on yesterday's bot tournament on KGS, it
is at http://www.weddslist.com/kgs/past/25/index.html
In the General Section you are referring to version 5 of HouseBot.
That
I don't know, but from the description list of atoms, perhaps
numbers were represented as linked lists of bits (using the facilities
built in to support linked lists of anything).
I don't believe that any non-toy version of lisp ever used anything
as ineffecient as representing numbers as
On Mon, 2007-04-09 at 17:36 +0100, Nick Wedd wrote:
I have written a short report on yesterday's bot tournament on KGS, it
is at http://www.weddslist.com/kgs/past/25/index.html
From the writeup:
CrazyStone has achieved an implausible 1k rating on KGS.
Yes, very implausible. It has only
.. then of course there were lisp machines
(brain short circuits as sparks fly and magic smoke is released.)
s.
TV dinner still cooling?
Check out Tonight's Picks on Yahoo! TV.
http://tv.yahoo.com/
Le lundi 9 avril 2007 14:06, Don Dailey a écrit :
But the point is that
as long as you can provide time and memory you will get improvement
until perfect play is reached.
Is there any proof that heavy player converge toward the same solution as
the pure random playout ?
With infinite
On Tue, 2007-04-10 at 00:06 +0200, alain Baeckeroot wrote:
Le lundi 9 avril 2007 14:06, Don Dailey a écrit :
But the point is that
as long as you can provide time and memory you will get improvement
until perfect play is reached.
Is there any proof that heavy player converge toward the
On 4/10/07, alain Baeckeroot [EMAIL PROTECTED] wrote:
Le lundi 9 avril 2007 14:06, Don Dailey a écrit:
But the point is that
as long as you can provide time and memory you will get improvement
until perfect play is reached.
Is there any proof that heavy player converge toward the same
With infinite resource, i agree that random playout will find the
best move.
But it seems that nothing is guaranteed for heavy playout.
As Don pointed out before, the reason it converges to perfect play is
because of the UCT part, not because of the playout part.
If the playout part prunes
With a badly designed play-out algorithm you may have a
horribly inefficent search - but it would eventually still
find the best move in principle.
- Don
On Tue, 2007-04-10 at 09:16 +0900, Darren Cook wrote:
With infinite resource, i agree that random playout will find the
best move.
But
I just updated the viewer again to version 0.31
I will not longer announce client updates unless
they address a serious bug or problem or amazing
new functionality Instead, I will give the
latest version number on the CGOS webpage.
In this case, there is probably no need to upgrade.
The
Don Dailey wrote:
(snip)
In my opinion, the insight that Chrilly articulated was that all of
sudden we are now all using some type of global search - the very
idea was considered blasphemy just 2 or 3 years ago.
That may be too strong a statement. It may have not been popular but
many people
Erik van der Werf wrote:
On 4/10/07, alain Baeckeroot [EMAIL PROTECTED] wrote:
Le lundi 9 avril 2007 14:06, Don Dailey a écrit:
But the point is that
as long as you can provide time and memory you will get improvement
until perfect play is reached.
Is there any proof that heavy player
19 matches
Mail list logo
