Hello,
my point was not to report this very long time thinking, which is very rare
(a few over thousands of games) in level 16.
It was more that GnuGo is already very strong in level 8, and incredibly
fast. And putting it at a better level (like 16) does not improve its
strength so much, so testi
2007/1/11, Don Dailey <[EMAIL PROTECTED]>:
50 X speedup sound rather impressive but it's not that much. It's
probably
made go programs about 2 or 3 stones stronger over the few years that it
took to get hardward 50X faster about what you would expect.
But it is hardly that much. Current pr
Hello,
I answer here on the discussion because I think it is more relevant to what
I wanted to say. Sorry not to answer to the lasts posts.
The computer go guys don't think of performance as a function of time,
only as a kind of absolute, it plays good or it doesn't.
I think it simply comes
On 1/10/07, Łukasz Lew <[EMAIL PROTECTED]> wrote:
On 1/10/07, Don Dailey <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-10 at 12:12 +0100, Łukasz Lew wrote:
> > > The interesting thing is that it can do a lot more play-outs when
> > > when X is high, although it is less strong. I need to understa
> I still don't understand your point. Are you just trying to say
> computers have a long way to go to beat really strong humans?
nope -- i'm saying that until extra time makes a measurable
difference in the strength of a program, worrying about how
much time a program spends on any particular a
A decade ago only a few programmers (in computer go) even knew what
scalability was. Most of the programmers were writing patterns
and not focused on scalability and this hurt them.
I believe it's starting to become more appreciated and the skill
will improve more rapidly. Of course there is s
On Thu, 2007-01-11 at 09:30 +0100, Sylvain Gelly wrote:
> So GnuGo and commercial programs have been optimized to play strong in
> very few time. For them, long thinking time is simply not relevant. It
> is not the same goal.
Hi Sylvain,
What I'm saying is that the programmers don't realize thei
On Thu, 2007-01-11 at 04:18 -0800, steve uurtamo wrote:
> > I still don't understand your point. Are you just trying to say
> > computers have a long way to go to beat really strong humans?
>
> nope -- i'm saying that until extra time makes a measurable
> difference in the strength of a program,
> Well then the time is now. Look at the Sylvain's post on the
> scalability of Mogo.
if the improvement continues to hold with more doublings, that's
great. i am perhaps under the misguided opinion that there are all
kinds of structural reasons why the best 'scalable' programs can't
arbitraril
Since we can no longer count on doubling single-processor speed every 18 months,
go programs will need to scale across multiple processors. Dual-core systems
are
common; a pair of duos can be had for $5K or so. IBM sells four dual-core
processors
in a single rackmount chassis, and can be expect
2007/1/11, steve uurtamo <[EMAIL PROTECTED]>:
> Well then the time is now. Look at the Sylvain's post on the
> scalability of Mogo.
if the improvement continues to hold with more doublings, that's
great.
I did not do further experiments as 35k simulations per move already takes
30s per move
On Thu, 2007-01-11 at 07:40 -0500, Don Dailey wrote:
> Of course there is some questions
> about how long Moore's law will hold.
If you are referring to CPU speed doubling (as opposed to transistor
count), then that has been over for at least 5 years.
"The Free Lunch Is Over: A Fundamental Turn T
I am currently working with different pruning methods for 19x19 go.
What worked
for Valkyria on 9x9 become much to slow on 19x19 where full board
evaluation of
several 100 moves simply does not work. During christmas I was able to
prune the
number of candiate moves to perhaps a factor 4-20 depen
On Thu, 2007-01-11 at 05:25 -0800, terry mcintyre wrote:
>
> Since we can no longer count on doubling single-processor speed every
> 18 months,
> go programs will need to scale across multiple processors. Dual-core
> systems are
> common; a pair of duos can be had for $5K or so. IBM sells
> four
On Thu, 2007-01-11 at 07:52 -0500, Don Dailey wrote:
> I agree that Gnugo was written in an absolute non-scalable style.
> What
> Gnugo does is continually upgrade from year to year.They are
> making
> their program scale in a painfully manual way.
I want to clarify what I said about Gnugo.
Hello Magnus,
I am glad to hear your experiment in 19x19.
Your pruning is based on expert go knowledge or another statistic?
Do have some statistics of the level of your pruning method against another
program (let's say gnugo :)) in 19x19?
Sylvain
2007/1/11, Magnus Persson <[EMAIL PROTECTED]>:
- Original Message -
From: "Jeff Nowakowski" <[EMAIL PROTECTED]>
To: "computer-go"
Sent: Thursday, January 11, 2007 3:37 PM
Subject: Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 07:40 -0500, Don Dailey wrote:
Of course there is some questions
about how long Mo
Hi Magnus,
I don't understand who the players were in the 9 handicap game.
Who received the handicap and who was Valkyria's opponent?
Was the opponent the un-pruned version of Valkyria?
more comments below ...
On Thu, 2007-01-11 at 15:38 +0100, Magnus Persson wrote:
> I am currently working wi
> The bus problem is a general one. E.g. modern graphic cards have a very
> powerfull GPU. One could use this e.g. for the computation of neural
> networks. The theoretic speedup is impressive, but the practical is low or
> it even slows down things. The neural-network-computation must - in
> c
Quoting Don Dailey <[EMAIL PROTECTED]>:
I don't understand who the players were in the 9 handicap game.
Who received the handicap and who was Valkyria's opponent?
Was the opponent the un-pruned version of Valkyria?
No, the opponent was myself, european 2 Dan as white taking a 9 handicap on
19x
But often it also suddenly pick a really bad move and play it so the
descrioption above is a little idealized.
Did you try picking the move with the highest number of simulations rather
than the higher average? This only modification gave MoGo a +10% against
gnugo in 19x19 (from 40% to 50% wit
On Thu, 2007-01-11 at 17:13 +0100, Magnus Persson wrote:
> When I watch Valkyria analyze a 19x19 position it often goees like
> this:
>
> For the first 30 seconds or so it almost random, it does not have the
> statistical power to pick out good moves.
>
> Then it starts jump around between some m
Magnus,
I applied my analogy to Mogo, but I really meant any good UCT
program such as yours - I just forgot who I was responding to
in my last email.
- Don
On Thu, 2007-01-11 at 17:13 +0100, Magnus Persson wrote:
> Quoting Don Dailey <[EMAIL PROTECTED]>:
> > I don't understand who the player
Quoting Sylvain Gelly <[EMAIL PROTECTED]>:
Hello Magnus,
I am glad to hear your experiment in 19x19.
Your pruning is based on expert go knowledge or another statistic?
Do have some statistics of the level of your pruning method against another
program (let's say gnugo :)) in 19x19?
There are
On Thu, 2007-01-11 at 17:19 +0100, Sylvain Gelly wrote:
> But often it also suddenly pick a really bad move and play it
> so the
> descrioption above is a little idealized.
>
>
> Did you try picking the move with the highest number of simulations
> rather than the higher
Quoting Sylvain Gelly <[EMAIL PROTECTED]>:
But often it also suddenly pick a really bad move and play it so the
descrioption above is a little idealized.
Did you try picking the move with the highest number of simulations rather
than the higher average? This only modification gave MoGo a +10
On Thu, 2007-01-11 at 17:44 +0100, Magnus Persson wrote:
> I think the ideal algorithm
> should be sensitive to the time left and start to prune moves
> accordingly.
This is a brilliant idea. As formulated, UCT has no sense that you
will
time-out shortly. It seems like it could be optimized
A very humble and thorough approach.
If we begin giving feelings to our programs, we will end saying that they
are no polite while passing too late, or making unsound invasions :-).
But I like that, why not giving a style to a program if we give some to a
human :-).
Sylvain
PS: please no f
On Thu, 2007-01-11 at 17:50 +0100, Sylvain Gelly wrote:
>A very humble and thorough approach.
> If we begin giving feelings to our programs, we will end saying that
> they are no polite while passing too late, or making unsound
> invasions :-).
> But I like that, why not giving a style
> Did you try picking the move with the highest number of simulations
> rather than the higher average? This only modification gave MoGo a
> +10% against gnugo in 19x19 (from 40% to 50% with 70k sim/move). And
> you can't say that it is a difficult modification to do :).
This is an important im
No I have not tried that yet. I think I have been planning to modify time
control, so that it will try to stop thinking when the highest winrate
has been
searched significantly more than the second highest winrate.
Perhaps a more elaborate time control should be useful. Maybe it is better
to co
Finally I use a pruning method I have been using with non-MC
programs where moves evaluated bad at ply n is pruned when they are
evaluate
again at ply n + 2 and their local neighborhood has not been changed. This
method is a little crude and perhaps a little risky, but the gains clearly
outweighs
Anyone recommend a good website or book that describes the
fundamentals of Go programming. Particularly what Monte Carlo is and
how to implent it in C.
Also what is a common language around here? I know C, C++, and Java.
-Josh
___
computer-go mailing l
Several on this list have experimented with concurrent processing - can you
share any overall summary of your results? How well does the problem scale? Any
advice?
With all this discussion of the benefits of long thinking time, have
any experiments been done with the Dragon Go Server or other tu
Hello,
Several on this list have experimented with concurrent processing - can you
share any overall summary of your results? How well does the problem scale?
Any advice?
The results I have so far are very simple. I have a very (very) simple
concurrent implementation of UCT. With 4 processors
Terry:
With all this discussion of the benefits of long thinking time, have
any experiments been done with the Dragon Go Server or other turn-based
servers? These servers would permit a 30 or 60-day game, and if your software
is able to ponder on the opponent's clock, you'll get
even more thi
Terry:
>>Several on this list have experimented with concurrent processing -
>>can you share any overall summary of your results? How well does
>> the problem scale? Any advice?
Sylvain:
>The results I have so far are very simple. I have a very (very)
> simple concurrent implementation of UCT
That level of concurrency is excellent! So it should be possible to do
about 3.6 times as many simulations per move in the same time,
memory permitting? From previous discussion, it seems that doubling
from 35,000 to 70,000 simulations was quite beneficial, so 3.6 times
35,000 should perhaps be ev
38 matches
Mail list logo
