Re: [Computer-go] 9x9 is last frontier?

[uurtamo .]

Thank you for being so kind in your response. I truly appreciate it.

s.

On Feb 28, 2018 6:32 PM, "Hideki Kato"  wrote:

> uurtamo .:  mail.gmail.com>:
> >I didn't mean to suggest that I can or will solve this problem tomorrow.
> >
> >What I meant to say is that it is clearly obvious that 9x9 is not immune
> to
> >being destroyed -- it's not what people play professionally (or at least
> is
> >not what is most famous for being played professionally), so it is going
> to
> >stand alone for a little while; it hasn't been the main focus yet. I
> >understand that it technically has features such as: very tiny point
> >differences; mostly being tactical. I don't think or have reason to
> believe
> >that that makes it somehow immune.
> >
> >What concerns me is pseudo-technical explanations for why it's harder to
> >beat humans at 9x9 than at 19x19. Saying that it's harder at 9x9 seems
> like
> >an excuse to explain (or hopefully justify) how the game is still in the
> >hands of humans. This feels very strongly like a justification for how "go
> >is still really hard for computers". Which, I suppose, we can break down
> >into lots of little subcases and worry about. The tiny point difference
> >issue is interesting; it means that things need to be super tight (less
> >room for sloppy play). Checkers also has this feature.
> >
> >The reality, in my unjustified opinion, is that this will be a solved
> >problem once it has obtained enough focus.
>
> I'm suspecious.  The value network (VN) is not enough for
> 9x9 because VN can't approximate value functions at enough
> detail.  This is also a problem on 19x19 but the advantages
> VN gives at silent positions is big enough (actually a few
> points) to beat top level human players.  I believe another
> idea is necessary for 9x9.
> #One possible (?) simple solution: if the inference speed of
> the policy network gets 100 or more times faster then we can
> use PN directly in rollouts.  This may make VN useless.
>
> Go is still hard for both human and computers :).
>
> Hideki
>
> >s.
> >
> >
> >On Fri, Feb 23, 2018 at 6:12 PM, Hideki Kato 
> wrote:
> >
> >> uurtamo .:  >> 1vhk7t...@mail.gmail.com>:
> >> >Slow down there, hombre.
> >> >
> >> >There's no secret sauce to 9x9 other than that it isn't the current
> focus
> >> >of people.
> >> >
> >> >Just like 7x7 isn't immune.
> >> >
> >> >A computer program for 9x9, funded, backed by halfway serious people,
> and
> >> >focused on the task, will *destroy* human opponents at any time it
> needs
> >> to.
> >>
> >> Why do you think (or believe) so?  I'd like to say there
> >> is no evidence so far.
> >>
> >> >If you believe that there is a special reason that 9x9 is harder than
> >> >19x19, then I'm super interested to hear that. But it's not harder for
> >> >computers. It's just not what people have been focusing on.
> >>
> >> 9x9 is not harder than 19x19 as a game.  However:  (1) Value
> >> networks, the key components to beat human on 19x19, work
> >> fine only on static positions but 9x9 has almost no such
> >> positions.   (2) Humans can play much better on 9x9
> >> than 19x19.  Top level professionals can read-out at near
> >> end of the middle stage of a game in less than 30 min with
> >> one point accuracy of the score, for example.
> >>
> >> Humans are not good at global evaluation of larger boards so
> >> bots can beat top professionals on 19x19 but this does not
> >> apply 9x9.  The size of the board is important because
> >> value networks are not universal, ie, approximate the
> >> value function not so presicely, mainly due to
> >> the number of training data is limited in practice (up to
> >> 10^8 while the number of possible input positions is greater
> >> than, at least, 10^20).  One more reason, there are no
> >> algorithm to solve double ko. This is not so big problem on
> >> 19x19 but 9x9.
> >>
> >> Best, Hideki
> >>
> >> >s.
> >> >
> >> >On Feb 23, 2018 4:49 PM, "Hideki Kato"  wrote:
> >> >
> >> >> That's not the point, Petri.  9x9 has almost no "silent"
> >> >> or "static" positons which value networks superb humans.
> >> >> On 9x9 boards, Kos, especially double Kos and two step Kos
> >> >> are important but MCTS still works worse for them, for
> >> >> examples.  Human professionals are much better at life
> >> >> and complex local fights which dominate small board games
> >> >> because they can read deterministically and deeper than
> >> >> current MCTS bots in standard time settings (not blitz).
> >> >> Also it's well known that MCTS is not good at finding narrow
> >> >> and deep paths to win due to "averaging".  Ohashi 6p said
> >> >> that he couldn't lose against statiscal algorithms after the
> >> >> event in 2012.
> >> >>
> >> >> Best,
> >> >> Hideki
> >> >>
> >> >> Petri Pitkanen:  >> >> 3zrby3k9kjvmzah...@mail.gmail.com>:
> >> >> 

Re: [Computer-go] Using 9x9 policy on 13x13 and 19x19

[Cornelius]

Hi Sighris,

i have always thought that creating algorithms for arbitrary large go
boards should enlighten us in regards to playing on smaller go boards.

A humans performance doesn't differ that much on differently sized large
go boards and it scales pretty well. For example one would find it
rather easy to evaluate large dragons or ladders. The currently used
neural algorithms (NNs) do not perform well in this regard.

Maybe some form of RNN could be integrated into the evaluation.


BR,
Cornelius


Am 24.02.2018 um 08:23 schrieb Sighris:
> I'm curious, does anybody have any interest in programs for 23x23 (or
> larger) Go boards?
> 
> BR,
> Sighris
> 
> 
> On Fri, Feb 23, 2018 at 8:58 AM, Erik van der Werf > wrote:
> 
>> In the old days I trained separate move predictors on 9x9 games and on
>> 19x19 games. In my case, the ones trained on 19x19 games beat the ones
>> trained on 9x9 games also on the 9x9 board. Perhaps it was just because of
>> was having better data from 19x19, but I thought it was interesting to see
>> that the 19x19 predictor generalized well to smaller boards.
>>
>> I suppose the result you see can easily be explained; the big board policy
>> learns about large scale and small scale fights, while the small board
>> policy doesn't know anything about large scale fights.
>>
>> BR,
>> Erik
>>
>>
>> On Fri, Feb 23, 2018 at 5:11 PM, Hiroshi Yamashita 
>> wrote:
>>
>>> Hi,
>>>
>>> Using 19x19 policy on 9x9 and 13x13 is effective.
>>> But opposite is?
>>> I made 9x9 policy from Aya's 10k playout/move selfplay.
>>>
>>> Using 9x9 policy on 13x13 and 19x19
>>> 19x19 DCNNAyaF128from9x91799
>>> 13x13 DCNNAyaF128from9x91900
>>> 9x9   DCNN_AyaF128a558x12290
>>>
>>> Using 19x19 policy on 9x9 and 13x13
>>> 19x19 DCNN_AyaF128a523x12345
>>> 13x13 DCNNAya795F128a5232354
>>> 9x9   DCNN_AyaF128a523x12179
>>>
>>> 19x19 policy is similar strength on 13x13 and 166 Elo weaker on 9x9.
>>> 9x9 policy is 390 Elo weaker on 13x13, and 491 Elo weaker on 19x19.
>>> It seems smaller board is more useless than bigger board...
>>>
>>> Note:
>>> All programs select maximum policy without search.
>>> All programs use opening book.
>>> 19x19 policy is Filter128, Layer 12, without Batch Normalization.
>>> 9x9 policy is Filter128, Layer 11, without Batch Normalization.
>>> 19x19 policy is made from pro 78000 games, GoGoD.
>>> 9x9 policy is made from 10k/move. It is CGOS 2892(Aya797c_p1v1_10k).
>>> Ratings are BayesElo.
>>>
>>> Thanks,
>>> Hiroshi Yamashita
>>>
>>> ___
>>> Computer-go mailing list
>>
>>
>> ___
>> Computer-go mailing list
> 
> 
> 
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> 

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] 9x9 is last frontier?

[Hideki Kato]

uurtamo .: :
>I didn't mean to suggest that I can or will solve this problem tomorrow.
>
>What I meant to say is that it is clearly obvious that 9x9 is not immune to
>being destroyed -- it's not what people play professionally (or at least is
>not what is most famous for being played professionally), so it is going to
>stand alone for a little while; it hasn't been the main focus yet. I
>understand that it technically has features such as: very tiny point
>differences; mostly being tactical. I don't think or have reason to believe
>that that makes it somehow immune.
>
>What concerns me is pseudo-technical explanations for why it's harder to
>beat humans at 9x9 than at 19x19. Saying that it's harder at 9x9 seems like
>an excuse to explain (or hopefully justify) how the game is still in the
>hands of humans. This feels very strongly like a justification for how "go
>is still really hard for computers". Which, I suppose, we can break down
>into lots of little subcases and worry about. The tiny point difference
>issue is interesting; it means that things need to be super tight (less
>room for sloppy play). Checkers also has this feature.
>
>The reality, in my unjustified opinion, is that this will be a solved
>problem once it has obtained enough focus.

I'm suspecious.  The value network (VN) is not enough for 
9x9 because VN can't approximate value functions at enough 
detail.  This is also a problem on 19x19 but the advantages 
VN gives at silent positions is big enough (actually a few 
points) to beat top level human players.  I believe another 
idea is necessary for 9x9.  
#One possible (?) simple solution: if the inference speed of 
the policy network gets 100 or more times faster then we can 
use PN directly in rollouts.  This may make VN useless.

Go is still hard for both human and computers :).

Hideki

>s.
>
>
>On Fri, Feb 23, 2018 at 6:12 PM, Hideki Kato  wrote:
>
>> uurtamo .: > 1vhk7t...@mail.gmail.com>:
>> >Slow down there, hombre.
>> >
>> >There's no secret sauce to 9x9 other than that it isn't the current focus
>> >of people.
>> >
>> >Just like 7x7 isn't immune.
>> >
>> >A computer program for 9x9, funded, backed by halfway serious people, and
>> >focused on the task, will *destroy* human opponents at any time it needs
>> to.
>>
>> Why do you think (or believe) so?  I'd like to say there
>> is no evidence so far.
>>
>> >If you believe that there is a special reason that 9x9 is harder than
>> >19x19, then I'm super interested to hear that. But it's not harder for
>> >computers. It's just not what people have been focusing on.
>>
>> 9x9 is not harder than 19x19 as a game.  However:  (1) Value
>> networks, the key components to beat human on 19x19, work
>> fine only on static positions but 9x9 has almost no such
>> positions.   (2) Humans can play much better on 9x9
>> than 19x19.  Top level professionals can read-out at near
>> end of the middle stage of a game in less than 30 min with
>> one point accuracy of the score, for example.
>>
>> Humans are not good at global evaluation of larger boards so
>> bots can beat top professionals on 19x19 but this does not
>> apply 9x9.  The size of the board is important because
>> value networks are not universal, ie, approximate the
>> value function not so presicely, mainly due to
>> the number of training data is limited in practice (up to
>> 10^8 while the number of possible input positions is greater
>> than, at least, 10^20).  One more reason, there are no
>> algorithm to solve double ko. This is not so big problem on
>> 19x19 but 9x9.
>>
>> Best, Hideki
>>
>> >s.
>> >
>> >On Feb 23, 2018 4:49 PM, "Hideki Kato"  wrote:
>> >
>> >> That's not the point, Petri.  9x9 has almost no "silent"
>> >> or "static" positons which value networks superb humans.
>> >> On 9x9 boards, Kos, especially double Kos and two step Kos
>> >> are important but MCTS still works worse for them, for
>> >> examples.  Human professionals are much better at life
>> >> and complex local fights which dominate small board games
>> >> because they can read deterministically and deeper than
>> >> current MCTS bots in standard time settings (not blitz).
>> >> Also it's well known that MCTS is not good at finding narrow
>> >> and deep paths to win due to "averaging".  Ohashi 6p said
>> >> that he couldn't lose against statiscal algorithms after the
>> >> event in 2012.
>> >>
>> >> Best,
>> >> Hideki
>> >>
>> >> Petri Pitkanen: > >> 3zrby3k9kjvmzah...@mail.gmail.com>:
>> >> >elo-range in 9x9 smaller than 19x19. One just cannot be hugelyl better
>> >> than
>> >> >the other is such limitted game
>> >> >
>> >> >2018-02-23 21:15 GMT+02:00 Hiroshi Yamashita :
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> Top 19x19 program reaches 4200 BayesElo on CGOS. But 3100 in 9x9.
>> >> >> Maybe it is because people don't have much interest in 

Re: [Computer-go] Crazy Stone is back

[Hideki Kato]

A guidline for CGOS users:

Do self-play to pick-up few strongest programs at your site  
(never use CGOS for this purpose) and throw them into CGOS 
to evaluate their ratings among others.  Please note that 
CGOS is the valueable shared resource for all developers.

#We (mainly Hiroshi and me) are managing CGOS in such a 
way that a new program can have solid rating as quick as 
possible (ie, fewer games).  The best (quickest) case could 
be: one new (unrated) program and many anchor-like (ie, 
having stable rating) programs at every 200 to 300 Elo.  In 
this case, every game gives much information to estimate the 
rating of the new program.  More new, unrated programs 
slower the convergence.  Flooding is a very bad idea for 
all.

Best, Hideki

Hiroshi Yamashita: <35aed3ab-235f-adc2-b072-1b317982a...@bd.mbn.or.jp>:
>No Zen on CGOS is pity.
>
>To LZ-0xx-p1600-t1-r1 author,
>I think LZ-073-p1600-t1-r1 has BayesElo already.
>
> From LeelaZero page,
>73 2018-02-05 23:0654bfb7b8
>LZ-54bfb7-t1-p1600, BayesElo is 2903.
>
>Recalculating CGOS rating is not essential.
>And too many same kind bots running makes many selfplay matching.
>Its rating is more unreliable.
>Could you stop them, and run up to two or three bots which has no BayesElo?
>
>Thanks,
>Hiroshi Yamashita
>
>
>On 2018/02/28 17:12, Hideki Kato wrote:
>> Welcome back Remi!
>> 
>> On the 19x19 cgos, recently many LeelaZeros are running.
>> This flood is making CGOS less useful and so I'll reconnect
>> Zen after the flooding ends.  Sorry for inconvinience.
>> 
>> Hideki
>___
>Computer-go mailing list
>Computer-go@computer-go.org
>http://computer-go.org/mailman/listinfo/computer-go
-- 
Hideki Kato 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] 9x9 is last frontier?

[uurtamo .]

I didn't mean to suggest that I can or will solve this problem tomorrow.

What I meant to say is that it is clearly obvious that 9x9 is not immune to
being destroyed -- it's not what people play professionally (or at least is
not what is most famous for being played professionally), so it is going to
stand alone for a little while; it hasn't been the main focus yet. I
understand that it technically has features such as: very tiny point
differences; mostly being tactical. I don't think or have reason to believe
that that makes it somehow immune.

What concerns me is pseudo-technical explanations for why it's harder to
beat humans at 9x9 than at 19x19. Saying that it's harder at 9x9 seems like
an excuse to explain (or hopefully justify) how the game is still in the
hands of humans. This feels very strongly like a justification for how "go
is still really hard for computers". Which, I suppose, we can break down
into lots of little subcases and worry about. The tiny point difference
issue is interesting; it means that things need to be super tight (less
room for sloppy play). Checkers also has this feature.

The reality, in my unjustified opinion, is that this will be a solved
problem once it has obtained enough focus.

s.


On Fri, Feb 23, 2018 at 6:12 PM, Hideki Kato  wrote:

> uurtamo .:  1vhk7t...@mail.gmail.com>:
> >Slow down there, hombre.
> >
> >There's no secret sauce to 9x9 other than that it isn't the current focus
> >of people.
> >
> >Just like 7x7 isn't immune.
> >
> >A computer program for 9x9, funded, backed by halfway serious people, and
> >focused on the task, will *destroy* human opponents at any time it needs
> to.
>
> Why do you think (or believe) so?  I'd like to say there
> is no evidence so far.
>
> >If you believe that there is a special reason that 9x9 is harder than
> >19x19, then I'm super interested to hear that. But it's not harder for
> >computers. It's just not what people have been focusing on.
>
> 9x9 is not harder than 19x19 as a game.  However:  (1) Value
> networks, the key components to beat human on 19x19, work
> fine only on static positions but 9x9 has almost no such
> positions.   (2) Humans can play much better on 9x9
> than 19x19.  Top level professionals can read-out at near
> end of the middle stage of a game in less than 30 min with
> one point accuracy of the score, for example.
>
> Humans are not good at global evaluation of larger boards so
> bots can beat top professionals on 19x19 but this does not
> apply 9x9.  The size of the board is important because
> value networks are not universal, ie, approximate the
> value function not so presicely, mainly due to
> the number of training data is limited in practice (up to
> 10^8 while the number of possible input positions is greater
> than, at least, 10^20).  One more reason, there are no
> algorithm to solve double ko. This is not so big problem on
> 19x19 but 9x9.
>
> Best, Hideki
>
> >s.
> >
> >On Feb 23, 2018 4:49 PM, "Hideki Kato"  wrote:
> >
> >> That's not the point, Petri.  9x9 has almost no "silent"
> >> or "static" positons which value networks superb humans.
> >> On 9x9 boards, Kos, especially double Kos and two step Kos
> >> are important but MCTS still works worse for them, for
> >> examples.  Human professionals are much better at life
> >> and complex local fights which dominate small board games
> >> because they can read deterministically and deeper than
> >> current MCTS bots in standard time settings (not blitz).
> >> Also it's well known that MCTS is not good at finding narrow
> >> and deep paths to win due to "averaging".  Ohashi 6p said
> >> that he couldn't lose against statiscal algorithms after the
> >> event in 2012.
> >>
> >> Best,
> >> Hideki
> >>
> >> Petri Pitkanen:  >> 3zrby3k9kjvmzah...@mail.gmail.com>:
> >> >elo-range in 9x9 smaller than 19x19. One just cannot be hugelyl better
> >> than
> >> >the other is such limitted game
> >> >
> >> >2018-02-23 21:15 GMT+02:00 Hiroshi Yamashita :
> >> >
> >> >> Hi,
> >> >>
> >> >> Top 19x19 program reaches 4200 BayesElo on CGOS. But 3100 in 9x9.
> >> >> Maybe it is because people don't have much interest in 9x9.
> >> >> But it seems value network does not work well in 9x9.
> >> >> Weights_33_400 is maybe made by selfplay network. But it is 2946 in
> >9x9.
> >> >> Weights_31_3200 is 4069 in 19x19 though.
> >> >>
> >> >> In year 2012, Zen played 6 games against 3 Japanese Pros, and lost by
> >> 0-6.
> >> >> And it seems Zen's 9x9 strength does not change big even now.
> >> >> http://computer-go.org/pipermail/computer-go/2012-
> November/005556.html
> >> >>
> >> >> I feel there is still enough chance that human can beat best program
> in
> >> >> 9x9.
> >> >>
> >> >> Thanks,
> >> >> Hiroshi Yamashita
> >> >>
> >> >> ___
> >> >> Computer-go mailing list
> >> >> Computer-go@computer-go.org
> >> >> 

Re: [Computer-go] Crazy Stone is back

[Hiroshi Yamashita]

Hi Remi,

Wow, "Weights" is your engine. So my guess was right :-)
In 9x9 CGOS, did you train in 9x9, or just use 19x19 network?
Weights_33_400 is stronger than Weights_40_400.
Maybe it is because Weights_33_400 use CrazyStone's playout, and
 Weights_40_400 does not use?

Thanks,
Hiroshi Yamashita

On 2018/02/28 15:13, Rémi Coulom wrote:

Hi,

I have just connected the newest version of Crazy Stone to CGOS. It is based on the 
AlphaZero approach. The "Weights" engine were in fact previous experimental 
versions. CrazyStone-18.03 is using time control and pondering instead of a fixed number 
of evaluations per move. So it should be much stronger than Weights_31_3200.

Does anybody know who cronus is? It is _extremely_ strong. Its rating is low 
because it has had only weaker opponents, but it is undefeated so far, except 
for one loss on time, and some losses against other versions of itself. It has 
just won two games in a row against Crazy Stone.

I hope the other strong engines will reconnect, too.

Rémi
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go


___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Andy]

 Rémi, can you share any details about how you are training your network?
Are you doing self-play games? Do you have access to a large number of GPUs?



2018-02-28 13:04 GMT-06:00 David Wu :

> It's not even just liberties and semeai, it's also eyes. Consider for
> example a large dragon that has miai for 2 eyes in distant locations, and
> the opponent then takes one of them - you'd like the policy net to now
> suggest the other eye-making move far away. And you'd also like the value
> net to distinguish the three situations where the whole group has 2 eyes
> even when they are distant versus the ones where it doesn't.
>
> I've been doing experiments with somewhat smaller neural nets (roughly 4-7
> residual blocks = 8-14 layers), without sticking to an idealized "zero"
> approach. I've only experimented with policy nets so far, but presumably
> much of this should also transfer to a value net's understanding too.
>
> 1. One thing I tried was chain pooling, which was neat, but ultimately
> didn't seem promising:
> https://github.com/lightvector/GoNN#chain-pooling
> It solves all of these problems when the strings are solidly connected. It
> helps also when the strings are long but not quite solidly connected too,
> the information still propagates faster than without it. But of course, if
> there are lots of little strings forming a group, diagonal connections,
> bamboo joints, etc, then of course it won't help. And also chain pooling is
> computationally costly, at least in Tensorflow, and it might have negative
> effects on the rest of the neural net that I don't understand.
>
> 2. A new thing I've been trying recently that actually does seem
> moderately promising is dilated convolutions, although I'm still early in
> testing. They also help increase the speed of information propagation, and
> don't require solidly connected strings, and also are reasonably cheap.
>
> In particular: my residual blocks have 192 channels, so I tried taking
> several of the later residual blocks in the neural net and making 64 of the
> channels of the first convolution in each block use dilated convolutions
> (leaving 128 channels of regular convolutions), with dilation factors of 2
> or 3. Intuitively, the idea is that earlier blocks could learn to compute
> 2x2 or 3x3 connectivity patterns, and then the dilated convolutions in
> later residual blocks will be able to use that to propagate information
> several spaces at a time across connected groups or dragons.
>
> So far, indications are that this works. When I looked at it in various
> board positions, it helped in a variety of capturing race and
> large-dragon-two-eye-miai situations, correctly suggesting moves that the
> net without dilated convolutions would fail to find due to the move being
> too far away. Also dilated convolutions seem pretty cheap - it only
> slightly increases the computational cost of the net.
>
> So far, I've found that it doesn't significantly improve the overall loss
> function, presumably because now there are 128 channels instead of 192
> channels of ordinary convolutions, so in return for being better at
> long-distance interactions, the neural net has gotten worse at some local
> tactics. But it also hasn't gotten worse the way it would if I simply
> dropped the number of channels from 192 to 128 without adding any new
> channels, so the dilated convolutions are being "used" for real work.
>
> I'd be curious to hear if anyone else has tried dilated convolutions and
> what results they got. If there's anything at all to do other than just add
> more layers, I think they're the most promising thing I know of.
>
>
> On Wed, Feb 28, 2018 at 12:34 PM, Rémi Coulom  wrote:
>
>> 192 and 256 are the numbers of channels. They are fully connected, so the
>> number of 3x3 filters is 192^2, and 256^2.
>>
>> Having liberty counts and string size as input helps, but it solves only
>> a small part of the problem. You can't read a semeai from just the
>> liberty-count information.
>>
>> I tried to be clever and find ways to propagate information along strings
>> in the network. But all the techniques I tried make the network much
>> slower. Adding more layers is simple and works.
>>
>> Rémi
>>
>> - Mail original -
>> De: "Darren Cook" 
>> À: computer-go@computer-go.org
>> Envoyé: Mercredi 28 Février 2018 16:43:10
>> Objet: Re: [Computer-go] Crazy Stone is back
>>
>> > Weights_31_3200 is 20 layers of 192, 3200 board evaluations per move
>> > (no random playout). But it still has difficulties with very long
>> > strings. My next network will be 40 layers of 256, like Master.
>>
>> "long strings" here means solidly connected stones?
>>
>> The 192 vs. 256 is the number of 3x3 convolution filters?
>>
>> Has anyone been doing experiments with, say, 5x5 filters (and fewer
>> layers), and/or putting more raw information in (e.g. liberty counts -
>> which makes the long string problem go 

Re: [Computer-go] Crazy Stone is back

[David Wu]

It's not even just liberties and semeai, it's also eyes. Consider for
example a large dragon that has miai for 2 eyes in distant locations, and
the opponent then takes one of them - you'd like the policy net to now
suggest the other eye-making move far away. And you'd also like the value
net to distinguish the three situations where the whole group has 2 eyes
even when they are distant versus the ones where it doesn't.

I've been doing experiments with somewhat smaller neural nets (roughly 4-7
residual blocks = 8-14 layers), without sticking to an idealized "zero"
approach. I've only experimented with policy nets so far, but presumably
much of this should also transfer to a value net's understanding too.

1. One thing I tried was chain pooling, which was neat, but ultimately
didn't seem promising:
https://github.com/lightvector/GoNN#chain-pooling
It solves all of these problems when the strings are solidly connected. It
helps also when the strings are long but not quite solidly connected too,
the information still propagates faster than without it. But of course, if
there are lots of little strings forming a group, diagonal connections,
bamboo joints, etc, then of course it won't help. And also chain pooling is
computationally costly, at least in Tensorflow, and it might have negative
effects on the rest of the neural net that I don't understand.

2. A new thing I've been trying recently that actually does seem moderately
promising is dilated convolutions, although I'm still early in testing.
They also help increase the speed of information propagation, and don't
require solidly connected strings, and also are reasonably cheap.

In particular: my residual blocks have 192 channels, so I tried taking
several of the later residual blocks in the neural net and making 64 of the
channels of the first convolution in each block use dilated convolutions
(leaving 128 channels of regular convolutions), with dilation factors of 2
or 3. Intuitively, the idea is that earlier blocks could learn to compute
2x2 or 3x3 connectivity patterns, and then the dilated convolutions in
later residual blocks will be able to use that to propagate information
several spaces at a time across connected groups or dragons.

So far, indications are that this works. When I looked at it in various
board positions, it helped in a variety of capturing race and
large-dragon-two-eye-miai situations, correctly suggesting moves that the
net without dilated convolutions would fail to find due to the move being
too far away. Also dilated convolutions seem pretty cheap - it only
slightly increases the computational cost of the net.

So far, I've found that it doesn't significantly improve the overall loss
function, presumably because now there are 128 channels instead of 192
channels of ordinary convolutions, so in return for being better at
long-distance interactions, the neural net has gotten worse at some local
tactics. But it also hasn't gotten worse the way it would if I simply
dropped the number of channels from 192 to 128 without adding any new
channels, so the dilated convolutions are being "used" for real work.

I'd be curious to hear if anyone else has tried dilated convolutions and
what results they got. If there's anything at all to do other than just add
more layers, I think they're the most promising thing I know of.


On Wed, Feb 28, 2018 at 12:34 PM, Rémi Coulom  wrote:

> 192 and 256 are the numbers of channels. They are fully connected, so the
> number of 3x3 filters is 192^2, and 256^2.
>
> Having liberty counts and string size as input helps, but it solves only a
> small part of the problem. You can't read a semeai from just the
> liberty-count information.
>
> I tried to be clever and find ways to propagate information along strings
> in the network. But all the techniques I tried make the network much
> slower. Adding more layers is simple and works.
>
> Rémi
>
> - Mail original -
> De: "Darren Cook" 
> À: computer-go@computer-go.org
> Envoyé: Mercredi 28 Février 2018 16:43:10
> Objet: Re: [Computer-go] Crazy Stone is back
>
> > Weights_31_3200 is 20 layers of 192, 3200 board evaluations per move
> > (no random playout). But it still has difficulties with very long
> > strings. My next network will be 40 layers of 256, like Master.
>
> "long strings" here means solidly connected stones?
>
> The 192 vs. 256 is the number of 3x3 convolution filters?
>
> Has anyone been doing experiments with, say, 5x5 filters (and fewer
> layers), and/or putting more raw information in (e.g. liberty counts -
> which makes the long string problem go away, if I've understood
> correctly what that is)?
>
> Darren
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> 

Re: [Computer-go] Exploiting Cyclic Symmetry in Convolutional Neural Networks

[Steven Clark]

See also: Oriented Response Networks https://arxiv.org/abs/1701.01833

On Wed, Feb 28, 2018 at 11:40 AM, Jonathan Roy  wrote:

> I'm curious if anyone has applied this idea in their Go software, and what
> results you obtained? It is a way to make rotations (and transpositions
> with more effort) go away as an issue, regardless of the way you input the
> board you'd get the same result back out. Short summary from the paper (
> https://arxiv.org/pdf/1602.02660.pdf):
>
> We have introduced a framework for building rotation
> equivariant neural networks, using four new layers which
> can easily be inserted into existing network architectures.
> Beyond adapting the minibatch size used for training, no
> further modifications are required. We demonstrated improved
> performance of the resulting equivariant networks
> on datasets which exhibit full rotational symmetry, while
> reducing the number of parameters. A fast GPU implementation
> of the rolling operation for Theano (using
> CUDA kernels) is available at https://github.com/benanne/kaggle-ndsb.
>
> It was apparently used by this science competition winner:
>
> http://benanne.github.io/2015/03/17/plankton.html
>
> And there's related codebase here that implements the paper Group
> Equivariant Convolutional Networks (https://tacocohen.files.
> wordpress.com/2016/06/gcnn.pdf).
>
> https://github.com/tscohen/gconv_experiments
>
> The paper makes it sound like implementing for rotation would be straight
> forward, and implementing for transposition more difficult but also
> doable.Which sounds perfect for Go AI applications.
>
> -Jonathan
>
>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Rémi Coulom]

192 and 256 are the numbers of channels. They are fully connected, so the 
number of 3x3 filters is 192^2, and 256^2.

Having liberty counts and string size as input helps, but it solves only a 
small part of the problem. You can't read a semeai from just the liberty-count 
information.

I tried to be clever and find ways to propagate information along strings in 
the network. But all the techniques I tried make the network much slower. 
Adding more layers is simple and works.

Rémi

- Mail original -
De: "Darren Cook" 
À: computer-go@computer-go.org
Envoyé: Mercredi 28 Février 2018 16:43:10
Objet: Re: [Computer-go] Crazy Stone is back

> Weights_31_3200 is 20 layers of 192, 3200 board evaluations per move
> (no random playout). But it still has difficulties with very long
> strings. My next network will be 40 layers of 256, like Master. 

"long strings" here means solidly connected stones?

The 192 vs. 256 is the number of 3x3 convolution filters?

Has anyone been doing experiments with, say, 5x5 filters (and fewer
layers), and/or putting more raw information in (e.g. liberty counts -
which makes the long string problem go away, if I've understood
correctly what that is)?

Darren
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Exploiting Cyclic Symmetry in Convolutional Neural Networks

[Jonathan Roy]

>
> To follow up on the paper I listed earlier I just found this link with a
> long list of related papers:
>
> http://www.arxiv-sanity.com/1705.08623v1
>
> Many from 2016-2018 and all dealing with neural networks and ways to solve
> rotation. Deep Rotation Equivariant Network (
> http://arxiv.org/pdf/1705.08623v1.pdf) is a direct response to
> "Exploiting Cyclic Symmetry in Convolutional Neural Networks" with an
> alternative approach that uses less memory and is twice as fast. Code
> provided here https://github.com/microljy/DREN.
>
> -Jonathan
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

[Computer-go] Exploiting Cyclic Symmetry in Convolutional Neural Networks

[Jonathan Roy]

I'm curious if anyone has applied this idea in their Go software, and what
results you obtained? It is a way to make rotations (and transpositions
with more effort) go away as an issue, regardless of the way you input the
board you'd get the same result back out. Short summary from the paper (
https://arxiv.org/pdf/1602.02660.pdf):

We have introduced a framework for building rotation
equivariant neural networks, using four new layers which
can easily be inserted into existing network architectures.
Beyond adapting the minibatch size used for training, no
further modifications are required. We demonstrated improved
performance of the resulting equivariant networks
on datasets which exhibit full rotational symmetry, while
reducing the number of parameters. A fast GPU implementation
of the rolling operation for Theano (using
CUDA kernels) is available at https://github.com/benanne/kaggle-ndsb.

It was apparently used by this science competition winner:

http://benanne.github.io/2015/03/17/plankton.html

And there's related codebase here that implements the paper Group
Equivariant Convolutional Networks (
https://tacocohen.files.wordpress.com/2016/06/gcnn.pdf).

https://github.com/tscohen/gconv_experiments

The paper makes it sound like implementing for rotation would be straight
forward, and implementing for transposition more difficult but also
doable.Which sounds perfect for Go AI applications.

-Jonathan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Darren Cook]

> Weights_31_3200 is 20 layers of 192, 3200 board evaluations per move
> (no random playout). But it still has difficulties with very long
> strings. My next network will be 40 layers of 256, like Master. 

"long strings" here means solidly connected stones?

The 192 vs. 256 is the number of 3x3 convolution filters?

Has anyone been doing experiments with, say, 5x5 filters (and fewer
layers), and/or putting more raw information in (e.g. liberty counts -
which makes the long string problem go away, if I've understood
correctly what that is)?

Darren
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Rémi Coulom]

Hi,

Thanks Peter for running Leela. I don't think the many LZ instances cause a big 
problem.

It's a pity Zen did not play cronus. cronus is very impressive. The next run of 
Bayeselo might move cronus to the top. zero40b is very strong too. The new wave 
of AlphaZero clones will become considerably stronger than the current Zen.

Weights_31_3200 is 20 layers of 192, 3200 board evaluations per move (no random 
playout). But it still has difficulties with very long strings. My next network 
will be 40 layers of 256, like Master. I expect it will become much stronger.

Rémi

- Mail original -
De: "Peter Wen" 
À: computer-go@computer-go.org
Envoyé: Mercredi 28 Février 2018 14:38:01
Objet: Re: [Computer-go] Crazy Stone is back



Hi Hiroshi, 


I've turned off half of the LZ instances and hopefully Hideki will run Zen 
again. The various versions of Zen were the most useful high ranking anchors on 
CGOS. 



There have been many changes to LZ's engine supposed to make it stronger, so 
I'd like to know if the ratings are actually different. Different people ran 
the original ones with the wrong configuration as the names were hashes, making 
their ratings unreliable. 


Thank you Hiroshi for hosting CGOS, it's been invaluable as a source of 
verification. 



Peter 


On Wed, Feb 28, 2018 at 3:50 AM, Hiroshi Yamashita < y...@bd.mbn.or.jp > wrote: 


No Zen on CGOS is pity. 

To LZ-0xx-p1600-t1-r1 author, 
I think LZ-073-p1600-t1-r1 has BayesElo already. 

From LeelaZero page, 
73 2018-02-05 23:06 54bfb7b8 
LZ-54bfb7-t1-p1600, BayesElo is 2903. 

Recalculating CGOS rating is not essential. 
And too many same kind bots running makes many selfplay matching. 
Its rating is more unreliable. 
Could you stop them, and run up to two or three bots which has no BayesElo? 

Thanks, 
Hiroshi Yamashita 


On 2018/02/28 17:12, Hideki Kato wrote: 


Welcome back Remi! 

On the 19x19 cgos, recently many LeelaZeros are running. 
This flood is making CGOS less useful and so I'll reconnect 
Zen after the flooding ends. Sorry for inconvinience. 

Hideki 


___ 
Computer-go mailing list 
Computer-go@computer-go.org 
http://computer-go.org/mailman/listinfo/computer-go 

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Peter Wen]

Disclaimer: I only run the LZ-0xx-p1600-t1-r1 bots.

On Wed, Feb 28, 2018 at 8:38 AM, Peter Wen  wrote:

> Hi Hiroshi,
>
> I've turned off half of the LZ instances and hopefully Hideki will run Zen
> again. The various versions of Zen were the most useful high ranking
> anchors on CGOS.
>
> There have been many changes to LZ's engine supposed to make it stronger,
> so I'd like to know if the ratings are actually different. Different people
> ran the original ones with the wrong configuration as the names were
> hashes, making their ratings unreliable.
>
> Thank you Hiroshi for hosting CGOS, it's been invaluable as a source of
> verification.
>
> Peter
>
> On Wed, Feb 28, 2018 at 3:50 AM, Hiroshi Yamashita 
> wrote:
>
>> No Zen on CGOS is pity.
>>
>> To LZ-0xx-p1600-t1-r1 author,
>> I think LZ-073-p1600-t1-r1 has BayesElo already.
>>
>> From LeelaZero page,
>> 73  2018-02-05 23:0654bfb7b8
>> LZ-54bfb7-t1-p1600, BayesElo is 2903.
>>
>> Recalculating CGOS rating is not essential.
>> And too many same kind bots running makes many selfplay matching.
>> Its rating is more unreliable.
>> Could you stop them, and run up to two or three bots which has no
>> BayesElo?
>>
>> Thanks,
>> Hiroshi Yamashita
>>
>>
>> On 2018/02/28 17:12, Hideki Kato wrote:
>>
>>> Welcome back Remi!
>>>
>>> On the 19x19 cgos, recently many LeelaZeros are running.
>>> This flood is making CGOS less useful and so I'll reconnect
>>> Zen after the flooding ends.  Sorry for inconvinience.
>>>
>>> Hideki
>>>
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>>
>
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Peter Wen]

Hi Hiroshi,

I've turned off half of the LZ instances and hopefully Hideki will run Zen
again. The various versions of Zen were the most useful high ranking
anchors on CGOS.

There have been many changes to LZ's engine supposed to make it stronger,
so I'd like to know if the ratings are actually different. Different people
ran the original ones with the wrong configuration as the names were
hashes, making their ratings unreliable.

Thank you Hiroshi for hosting CGOS, it's been invaluable as a source of
verification.

Peter

On Wed, Feb 28, 2018 at 3:50 AM, Hiroshi Yamashita  wrote:

> No Zen on CGOS is pity.
>
> To LZ-0xx-p1600-t1-r1 author,
> I think LZ-073-p1600-t1-r1 has BayesElo already.
>
> From LeelaZero page,
> 73  2018-02-05 23:0654bfb7b8
> LZ-54bfb7-t1-p1600, BayesElo is 2903.
>
> Recalculating CGOS rating is not essential.
> And too many same kind bots running makes many selfplay matching.
> Its rating is more unreliable.
> Could you stop them, and run up to two or three bots which has no BayesElo?
>
> Thanks,
> Hiroshi Yamashita
>
>
> On 2018/02/28 17:12, Hideki Kato wrote:
>
>> Welcome back Remi!
>>
>> On the 19x19 cgos, recently many LeelaZeros are running.
>> This flood is making CGOS less useful and so I'll reconnect
>> Zen after the flooding ends.  Sorry for inconvinience.
>>
>> Hideki
>>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Hiroshi Yamashita]

No Zen on CGOS is pity.

To LZ-0xx-p1600-t1-r1 author,
I think LZ-073-p1600-t1-r1 has BayesElo already.

From LeelaZero page,
73  2018-02-05 23:0654bfb7b8
LZ-54bfb7-t1-p1600, BayesElo is 2903.

Recalculating CGOS rating is not essential.
And too many same kind bots running makes many selfplay matching.
Its rating is more unreliable.
Could you stop them, and run up to two or three bots which has no BayesElo?

Thanks,
Hiroshi Yamashita


On 2018/02/28 17:12, Hideki Kato wrote:

Welcome back Remi!

On the 19x19 cgos, recently many LeelaZeros are running.
This flood is making CGOS less useful and so I'll reconnect
Zen after the flooding ends.  Sorry for inconvinience.

Hideki

___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Crazy Stone is back

[Hideki Kato]

Welcome back Remi!

On the 19x19 cgos, recently many LeelaZeros are running.  
This flood is making CGOS less useful and so I'll reconnect 
Zen after the flooding ends.  Sorry for inconvinience.

Hideki

Remi Coulom: 
<1656424330.7641525.1519798424452.javamail.r...@spooler6-g27.priv.proxad.net>:
>Hi,

>

>I have just connected the newest version of Crazy Stone to CGOS. It is 
>based on the AlphaZero approach. The "Weights" engine were in fact previous 
>experimental versions. CrazyStone-18.03 is using time control and pondering 
>instead of a fixed number of evaluations per move. So it should be much 
>stronger than Weights_31_3200.

>

>Does anybody know who cronus is? It is _extremely_ strong. Its rating is 
>low because it has had only weaker opponents, but it is undefeated so far, 
>except for one loss on time, and some losses against other versions of 
>itself. It has just won two games in a row against Crazy Stone.

>

>I hope the other strong engines will reconnect, too.

>

>Rémi

>___

>Computer-go mailing list

>Computer-go@computer-go.org

>http://computer-go.org/mailman/listinfo/computer-go
-- 
Hideki Kato 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go