... when someone sucks, we usually don't distinguish
how much they suck so even if they improve a lot, we still think they
suck. And if you suck no one cares how much.
He's right. I suck and no one cares.
___
computer-go mailing list
computer-go@comp
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?
If so, that doesn't have anything to do with what Chrilly said
or my response to him.
On Wed, 2007-01-10 at 19:10 -0800, steve uurtamo wrote:
> i'm saying that if
We generally use level 10 or 12. We have found that very rarely on
level 15 GG will run off into the weeds, never (longer than 24 hours)
to make a move. This has also been reported by others at level 18. We
have never seen this happen at level 10 or 12.
Cheers,
David
On 10, Jan 2007, at
I would suggest the minor correction to say that any non-GNU
based program would have this hope. SlugGo already does this,
but I doubt it has this meaning.
Cheers,
David
On 10, Jan 2007, at 4:38 PM, steve uurtamo wrote:
as an example, if any program could give gnugo 9 stones
under these circ
i'm saying that if a factor of 50 extra time can make your program
strong enough to be 'impressive', then you know that you're within
a reasonable hardware 'scaling distance' of playing that strong at
regular timeframes.
if, on the other hand, you're *not* (which would be easy to see
by performing
On Wed, 2007-01-10 at 16:38 -0800, steve uurtamo wrote:
> in absolute terms, the time issue doesn't matter until
> some piece of code is good enough to beat a dan-level
> player on a 19x19 board at *any* physically realistic time
> constraint. which hasn't yet been demonstrated. the super
> slow m
in absolute terms, the time issue doesn't matter until
some piece of code is good enough to beat a dan-level
player on a 19x19 board at *any* physically realistic time
constraint. which hasn't yet been demonstrated. the super
slow motion tournament would be a good way for us to notice
when this ha
Chrilly,
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.
Us computer chess people are used to thinking of it as a function of
how fast the computer is and how much memory (along with how well the
code is written of
On Wed, 2007-01-10 at 18:37 +0100, Łukasz Lew 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
Hello,
in my experiments of MoGo against Gnu-Go (in 19x19 of course), with some
parameters making 65% win against GnuGo 3.6 level 8, I have 59% against
GnuGo 3.7.10 level 8, and 52% against GnuGo 3.7.10 level 16.
The confidence intervals are quite small as there are between 500 and 1000
games.
S
At 16:20 09/01/2007, you wrote:
i'd like to follow this up by saying that i'm interested
to see if anyone has compared winning percentage
in the following two situations:
i) maximize probability of win
ii) maximize probability of win until p_win > 1-eps, then maximize
total score among all
You must test with Gnu-Go level 16.. This is according to Stefan Mertin by
far the best mode. But it takes sometimes quite a long time till Gnu-Go
makes it move.
In your experiments Gun-Go played very fast. You played fast Blitz and
Gnu-Go had a big time handicap (besides Handtalk, which plays U
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 understand
> > why.
> >
> > Based on the paltry data I have now
I tested Gnugo against some commercial programs.
Gnugo is 3.7.10.
Level is default with --never-resign and --komi 6.5 option.
Commercial program is max level.
All game is Japanese rule and komi is 6.5.
gnugo wins losses winning rate average score
GinseiIgo5 (KCC Igo
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 understand
> > why.
> >
> > Based on the paltry data I have now it's a mistake to use X that
> > is very high.
And
It is possible that Your uniform playout part is a lot more efficient
than UCT part, because
of costly move choosing procedure (loop).
On last Computer and Games conference I and Jakub Pawlewicz published an
article describing 1+epsilon trick that increases efficiency of
proof-number search.
It
Hello,
Also on 19x19 mogos plays also some very slow moves in the beginning of
7 handicap game.
I guess that using (average_score / standard_deviation_of_score) instead
of
(winning_probability) should solve both problems at the same time.
yes you're right, MoGo is very weak in the opening gam
17 matches
Mail list logo
