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 wo
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 ac
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.
At 13:06 09/04/2007, Don wrote:
On Mon, 2007-04-09 at 05:30 -0400, Weston Markham wrote:
> On 4/8/07, Don Dailey <[EMAIL PROTECTED]> wrote:
>
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 numb
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 prob
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 Mon, 2007-04-09 at 09:47 -0400, [EMAIL PROTECTED] wrote:
> 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 peo
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 Lis
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
Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailm
-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 sho
I presume in the table that it should be 7 wins rather than 76 for MoGoBot?
On 4/9/07, Nick Wedd <[EMAIL PROTECTED]> 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
Nick
--
Nick Wedd[EMAIL PROTECTED]
___
>
>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 p
> .. 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/
___
The NEW and improved CGOS server is up and running.
You will need to get fresh client software and may
want to delete the old clients which will not work
any longer.
The protocol has not changed, so your old clients
would actually work if you modify the scripts. At
some point I will make
Martin Müller Pedersen wrote:
See also:
http://en.wikipedia.org/wiki/Bernoulli_process
Regards
That was obvious from the beginning and is applicable to
any experiment of probability p. It is the playout's case
because: same initial conditions => same p.
But my post goes a lot further than tha
Thanks to Brian, Rémi, Urban and Terry for pointing out various
mistakes.
Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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 resour
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
With infinite resource, i agree that random playout will find the best move.
But it seems that nothing is guaranted 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.
_
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 so
If the playout part prunes some moves, nothing is guaranteed.
- gg
Chris Fant: <[EMAIL PROTECTED]>:
>> With infinite resource, i agree that random playout will find the best move.
>> But it seems that nothing is guaranted for heavy playout.
>
>As Don pointed out before, the reason it converges to
>>> 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 pa
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.
>
I made some minor cosmetic changes to the
viewing client (to prevent it from cutting
off the "pass" move text in the game listing.)
Also, added a version number to the gamelets.
No need to upgrade unless you want to.
- Don
___
computer-go mailing l
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 onl
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 c
Thanks Chrilly. For anyone else interested, it is here:
http://www.xilinx.com/publications/xcellonline/xcell_53/xc_pdf/xc_hydra53.pdf
But, as you say, the "the search tree as an adaptable error filter"idea
is only mentioned in passing. I guess I'll just have to wait for Ulf
Lorenz to translate h
Ingo Althoeffer has published some time ago a theoretical article about this
idea. He called it "telescope" evaluation. According his theorectical findings
is the error propagation not better than the usual approach.
K.Chen proposed a similar approach. Use the mean of the last and second-last
ev
31 matches
Mail list logo
