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
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
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
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 their
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
arbitrarily
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
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
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
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. I'm
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 computer-go@computer-go.org
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
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
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
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%
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 moves
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 players
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%
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
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
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
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. With
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
26 matches
Mail list logo
