Christoph Birk: <[EMAIL PROTECTED]>:
>On Tue, 9 Sep 2008, Olivier Teytaud wrote:
>> testbed for
>> parallelization because it's more difficult) and as "real" targets (as there
>> are players
>> for both).
>
>Sorry, but there are (almost) no players for 9x9. To repeat
>D.Fotland's earlier comment: 9
>> testbed for parallelization because it's more difficult) and as
>> "real" targets (as there are players for both).
>
> Sorry, but there are (almost) no players for 9x9. To repeat
> D.Fotland's earlier comment: 9x9 is just for beginner's practice.
> It's not go.
I won't argue that 19x19 is pl
On Sep 8, 2008, at 11:45 AM, "Olivier Teytaud"
<[EMAIL PROTECTED]> wrote:
By my recent experiments, 8~9 * (threads - 1) ELO is lost. This
matches my earlier result well.
Do you have tricks for avoiding redundancies between simulations ?
I suggest simple tricks like "do not go to node X if
On Tue, 9 Sep 2008, Olivier Teytaud wrote:
testbed for
parallelization because it's more difficult) and as "real" targets (as there
are players
for both).
Sorry, but there are (almost) no players for 9x9. To repeat
D.Fotland's earlier comment: 9x9 is just for beginner's practice.
It's not go.
This beast goes online in 2011. Better start lobbying now for some Mogo
time.
By coincidence I was looking at the Top 500 list yesterday and the top
machine already does petaflop (peak) performance [1]. I wonder how many
playouts/second Mogo would do on that :-).
If you're looking for spare p
David Fotland wrote:
Can you put crazystone back on 19x19 so I can see if it is just a fluke
against fuego?
I added locality to the light playouts - play near last or second to last
move, and some code to handle long ladders in playouts. I don’t think this
is anything unusual.
I think you h
>
>
> The bright side here is that 9x9 is not really important but just
> a test bed. If it works for 19x19, that's good.
People moderately intested in Go could also claim that both 9x9 and 19x19
are
just testbeds for power plant management :-)
In my humble opinion, both are intesting, both as t
Christoph Birk wrote:
> On Tue, 9 Sep 2008, Olivier Teytaud wrote:
>> In 19x19, it's much better, but the MPI parallelization of 9x9 Go is
>> challenging.
>
> The bright side here is that 9x9 is not really important but just
> a test bed. If it works for 19x19, that's good.
The same problems wil
On Tue, 9 Sep 2008, Olivier Teytaud wrote:
In 19x19, it's much better, but the MPI parallelization of 9x9 Go is
challenging.
The bright side here is that 9x9 is not really important but just
a test bed. If it works for 19x19, that's good.
Christoph
___
Some main differences in mogo between 9x9 and 19x19:
- we have no pattern database for the tree in 9x9 (because we have not done
it yet, but perhaps it would be efficient),
and go-expertise (rules used for introducing a bias in the tree) is nearly
useless in 9x9.
- I have read that Rave values ar
Quoting David Fotland <[EMAIL PROTECTED]>:
Can you put crazystone back on 19x19 so I can see if it is just a fluke
against fuego?
I added locality to the light playouts - play near last or second to last
move, and some code to handle long ladders in playouts. I dont think this
is anything unu
Actually I see that I didnt test on 19x19 for a couple of weeks, so the
improved strength can be from any of a dozen changes I made and only tested
on 9x9.
David
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:computer-go-
> [EMAIL PROTECTED] On Behalf Of David Fotland
> Sent: Tue
So I guess you have seen the same effect. I have no size dependent code.
Can you tell us some of the things that make a big difference between 19x19 and
9x9? Do you turn off progressive unpruning for 9x9? Do you have a different
balance between exploration and exploitation?
David
Can you put crazystone back on 19x19 so I can see if it is just a fluke
against fuego?
I added locality to the light playouts - play near last or second to last
move, and some code to handle long ladders in playouts. I dont think this
is anything unusual.
Both should help 19x19, but I dont k
I made a change over the weekend, which looks like it makes 9x9 150 ELO
> weaker and 19x19 over 200 ELO stronger.
>
> We have plenty of size-dependent parameters and plenty of "if
(boardsize==19)" in MoGo for things like that :-)
___
computer-go mailing l
David Fotland wrote:
I made a change over the weekend, which looks like it makes 9x9 150 ELO
weaker and 19x19 over 200 ELO stronger.
Very strange.
David
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listi
I made a change over the weekend, which looks like it makes 9x9 150 ELO
weaker and 19x19 over 200 ELO stronger.
Very strange.
David
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
> MC is playing most "goal-directed" ("zielgerichtet"
> in German) when the position is balanced or when
> the side of MC is slightly behind. However, when
> MC is clearly ahead or clearly behind it is playing rather
> lazy.
At some point we were investigating that here, but only on small set
Olivier Teytaud: <[EMAIL PROTECTED]>:
>>
>>
>> Although I'm parallelizing in not SMP systems but a cluster of loosely
>> coupled (small) computers connected through moderate speed networks
>> using broadcasting positions, this may not change the vlaue of
>> avoiding redundancies. I'll study more
>
>
> Although I'm parallelizing in not SMP systems but a cluster of loosely
> coupled (small) computers connected through moderate speed networks
> using broadcasting positions, this may not change the vlaue of
> avoiding redundancies. I'll study more when implementing
> pre-knowledge or some. T
Olivier Teytaud: <[EMAIL PROTECTED]>:
>>
>>
>> Yes. I use Sylvain's fpu and decrease it a little before starting a
>> simulation, say, fpu *= 0.99. This is very simple and fast.
>
>
>Ok. Perhaps I'm wrong (I might misunderstand your solution and I might be
>wrong
>whenever I've understood :-) );
Part of the problems stem from that playouts are weak, and more
specifically notably weaker than the program itself.
To begin with, a consequence is that most areas of the board are less
clear than they should to playouts. This entails, I think, a preference
for probable points against sure point
>
>
> Yes. I use Sylvain's fpu and decrease it a little before starting a
> simulation, say, fpu *= 0.99. This is very simple and fast.
Ok. Perhaps I'm wrong (I might misunderstand your solution and I might be
wrong
whenever I've understood :-) ); but
- I think that this does not avoid redundan
23 matches
Mail list logo
