Hello all,
as perhaps some of you may be interested, I give here a link to a technical
report about MoGo. You can find there a lot of details about the ideas around
MoGo. While we tried to be as clear as possible, some details may lack. There
is still no "number" on this report, but this will c
On 1, Dec 2006, at 6:15 AM, Wodzu wrote:
- Original Message - From: "David Doshay" <[EMAIL PROTECTED]>
Also, my data shows that if I doubled the time allowed for
playing, thus
"using" the time gained from faster execution for doing deeper
lookahead,
the results did not improve,
Le Vendredi 01 Décembre 2006 21:26, steve uurtamo a écrit :
> > In fact, I think we say the same thing, simply using
> > different meaning for the
> > same word. By "random" you mean "uniformly random",
> > and I don't mean that, I
> > simply mean random (in the sense of random
> > variable).
>
> w
> In fact, I think we say the same thing, simply using
> different meaning for the
> same word. By "random" you mean "uniformly random",
> and I don't mean that, I
> simply mean random (in the sense of random
> variable).
what distribution is currently being used?
s.
___
> > I think I disagree
> > with the statement "an evaluation that only
> > understands final scores will not
> > make a strong go program" depending on what you mean
> > by random.
>
> here i will interject by agreeing with the
> statement that "an evaluation that only
> understands final scores wi
Quoting David Fotland <[EMAIL PROTECTED]>:
My point with the file I attached is not that it's a difficult position.
These fights are incredibly easy if you just add a few dozen lines of code
to count liberties correctly. To me it's as if a weak chess player says, my
program doesn’t need to und
On Fri, 2006-12-01 at 08:39 -0800, David Fotland wrote:
> What's included in an evaluation? Is each evaluation one random game, or a
> set of random games that gives good enough statistics about the value of a
> position?
When you say "random" it conjures up images of aimless wandering - but
the m
> I think I disagree
> with the statement "an evaluation that only
> understands final scores will not
> make a strong go program" depending on what you mean
> by random.
here i will interject by agreeing with the
statement that "an evaluation that only
understands final scores will not make a
Quoting [EMAIL PROTECTED]:
Also, there are a lot to improvements to do in MC in a quite short term, so I
share the point of view of Rémi, Don and some others when saying that MC
programs will fill the gap with classical programs in 19x19. And this can be
soon. Now, it is the work of the "classic
> I understand the definition of Monte Carlo. But when people talk about
> Monte Carlo go, they mean programs that evalutate random games, not
> professional games.
To be completely precise, professional games are also random games (if it was
not, all games between two players would always be
Each evaluation is one random game.
Sylvain
> What's included in an evaluation? Is each evaluation one random game, or a
> set of random games that gives good enough statistics about the value of a
> position?
>
> David
>
> > On a P4 3.0Ghz mono processor, the number of evaluations per
> > second
What's included in an evaluation? Is each evaluation one random game, or a
set of random games that gives good enough statistics about the value of a
position?
David
> On a P4 3.0Ghz mono processor, the number of evaluations per
> seconds is in the
> order of 4500/s in 9x9, 2500 in 13x13 and 1
>
> It is not what we said. At least it is not what I meant, and
> I think it is
> true for the others.
I was reacting to the two statements below. I didn't realize that this
opinion was not generally shared by the people developing monte carlo
programs.
>> I believe that MC will be the onl
- Original Message -
From: "David Doshay" <[EMAIL PROTECTED]>
To: "computer-go"
Sent: Thursday, November 30, 2006 11:44 PM
Subject: Re: [computer-go] Making Java much faster
I have been *so* tempted to either ignore this thread or rename it ...
On 30, Nov 2006, at 10:36 AM, Wodzu w
Le Vendredi 01 Décembre 2006 11:57, Chrilly a écrit :
> > On a P4 3.0Ghz mono processor, the number of evaluations per seconds is
> > in the
> > order of 4500/s in 9x9, 2500 in 13x13 and 1100 in 19x19.
>
> If one assumes 300 moves/Plies on 19x19 it would be about 330 KNodes/sec?
No, that just mean
On a P4 3.0Ghz mono processor, the number of evaluations per seconds is in
the
order of 4500/s in 9x9, 2500 in 13x13 and 1100 in 19x19.
If one assumes 300 moves/Plies on 19x19 it would be about 330 KNodes/sec?
Chrilly
___
computer-go mailing list
co
Le vendredi 1 décembre 2006 06:24, Don Dailey a écrit :
>
> On Thu, 2006-11-30 at 18:40 -0800, David Fotland wrote:
> > How does monte carlo go do with fights that are trivial to evaluate, but
> > hard to search?
>
> It's easy to construct problems that any program cannot handle including
> yours
Le Vendredi 01 Décembre 2006 08:48, Chrilly a écrit :
> > Are there any details, or publications, on what Mogo is doing at 19x19?
> > I'd thought consensus opinion here was that monte carlo scaled to 19x19
> > badly.
> >
> > Darren
>
> A very stupid question: What is Mogo, who has it written?
Hell
Hello,
> I'm not trying to pick a fight. I was responding to a bunch of people who
> think that really fast random search with a stupid evaluation will crush
> traditional programs next year.
It is not what we said. At least it is not what I meant, and I think it is
true for the others.
> Mont
Hello,
> On 11/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > To give an idea of the scale (at least for MoGo), 70k simulations/move
> > (with the best parameters) against gnugo 3.6/level 8 gives 89% in 9x9,
> > 68% in 13x13, 32% in 19x19.
>
> This is still not assessment of scalability.
20 matches
Mail list logo
