Re: [Computer-go] Project Leela Zero

[Michael Markefka]

That looks very interesting. Looking forward to some implementation of this
filtering down to the common ML libs.

On Mon, Mar 19, 2018 at 2:39 PM, Stefan Kaitschick 
wrote:

> Is this something LeelaZero might consider using?
> https://arxiv.org/pdf/1803.05407.pdf
> The last diagram is looking very impressive. It's not a game playing
> domain, but still.
> Maybe this averaging technique could help reduce the gap for a
> (relatively) low resource project like Leela.
>
>
> On Wed, Jan 10, 2018 at 12:28 AM, uurtamo .  wrote:
>
>> 4dan?
>>
>> On Jan 9, 2018 3:26 PM, "mic"  wrote:
>>
>>> Thank you very much.
>>>
>>> It will play on DGS as LeelaZero19 (without GPU support). I will start
>>> this night with an unrated test game against FuegoBot, one minute thinking
>>> time each. Then I will give it a rank, so it can get stronger by the time.
>>>
>>> Leela 0.11.0 (on DGS as LeelaBot19) has meanwhile reached a weak 4 dan
>>> rank, also without GPU support.
>>>
>>> -Michael.
>>>
>>> ---
>>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>>> https://www.avast.com/antivirus
>>>
>>> ___
>>> 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
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Go Tournament with hinteresting rules

[Michael Markefka]

>
>
>   The basic explanation for why this is not straightforward is that you
> never want your program to consider moves in the direction of
> low-probability wins, no matter how large margins they might have; the
> MC measurement function is very noisy with regards to individual samples.
>

I do wonder though whether a final score value network would work better
than MC here, and whether there could be a minimum win percentage threshold
that could work. I'd love to see someone implement a final score value
network and chose moves according to expected score or expected value
(expected winning percentage * expected final score), with a minimum filter
for expected winning percentage.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] World Go Championship

[Michael Markefka]

Just a wild guess, but I assume they'll go for the latest winner of the UEC
Cup as far as AI entrants are concerned.

On Tue, Nov 29, 2016 at 3:46 PM, "Ingo Althöfer" <3-hirn-ver...@gmx.de>
wrote:

> Hi Hideki,
>
> that sounds very interesting.
>
> > Nihon Kiin created a new Go tournament, "World Go Championship", which
> > will be held in March 21st to 23rd, in Osaka, Japan.
> >
> > Top three professional players from Japan, China and Korea and one
> > Computer Go program will attend.
>
> Big questions:
> * Where can computer programmers apply on behalf of their bots?
> * Will there be a qualifier tournament for bots?
>
> Looking forward to this event with big eyes,
> Ingo.
> ___
> 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] Deep Zen vs Cho Chikun -- Round 3

[Michael Markefka]

That sounds very promising. Any chance some of the improvements will filter
down into the current commercial version in the form of update patches?

On Wed, Nov 23, 2016 at 11:03 PM, Hideki Kato 
wrote:

> Thanks David.
>
> It's now.
>
> In the same afternoon, Zen vs Yonil Ha 6p was played on KGS as a part
> of Neyagawa Igo Shogi Festival in Neyagawa city, Osaka, Japan.
> (Zen19X vs neyagawa. The time was set 4 hours to avoid KGS's time
> control and actually a move was played in 30s).
>
> This Zen ran on a dual Xeon server with one nVidia GTX-1080 in my
> room.  I ran seven threads.  This shows recent Zen on a PC with a
> highend GPU is enough to beat pro at short-time settings.
>
> Also, Zen on a dual-core laptop (ThinkPad X250; Core i7 5600U@2.6 GHz)
> beat a pro a few times in personal trials (also fast games).
>
> Hideki
>
> David Fotland: <06c901d245a8$d41405f0$7c3c11d0$@smart-games.com>:
> >Congratulations to Zen for playing so well against a strong pro. It won't
> >be long until anyone can get a pro strength go program that runs on their
> >ordinary PC.
> >
> >David
> --
> Hideki Kato 
> ___
> 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] Timetable "Computers and Games 2016"

[Michael Markefka]

A_j_a, of course. Sorry for messing this up.

On Wed, Jun 22, 2016 at 8:27 PM, Michael Markefka
 wrote:
> Aya, thank you for giving us some insight into AlphaGo. We are all
> very much looking forward to it
>
> On Wed, Jun 22, 2016 at 5:29 PM, Aja Huang  wrote:
>>
>>
>> 2016-06-22 12:29 GMT+01:00 "Ingo Althöfer" <3-hirn-ver...@gmx.de>:
>>>
>>> Hi,
>>>
>>> the timetable for the conference "Computers and Games 2016"
>>> in Leiden (NL) is online now. COnference days are June 29 -
>>> July 01.
>>>
>>>
>>> https://www.conftool.net/cg2016/index.php?page=browseSessions&print=yes&doprint=yes&presentations=show
>>>
>>> At least 8 of the talks (including the keynote presentation by Aja Huang)
>>> are directly related to Go and computer Go.
>>
>>
>> Thanks Ingo.
>>
>> In my talk I will focus on the source of AlphaGo's power: policy and value
>> networks. I will also mention the status and conclusion of our investigation
>> on AlphaGo's problem in the 4th game against Lee Sedol.
>>
>> Looking forward to meeting you all there.
>>
>> Regards,
>> Aja
>>
>>>
>>>
>>> Ingo.
>>> ___
>>> 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] Timetable "Computers and Games 2016"

[Michael Markefka]

Aya, thank you for giving us some insight into AlphaGo. We are all
very much looking forward to it

On Wed, Jun 22, 2016 at 5:29 PM, Aja Huang  wrote:
>
>
> 2016-06-22 12:29 GMT+01:00 "Ingo Althöfer" <3-hirn-ver...@gmx.de>:
>>
>> Hi,
>>
>> the timetable for the conference "Computers and Games 2016"
>> in Leiden (NL) is online now. COnference days are June 29 -
>> July 01.
>>
>>
>> https://www.conftool.net/cg2016/index.php?page=browseSessions&print=yes&doprint=yes&presentations=show
>>
>> At least 8 of the talks (including the keynote presentation by Aja Huang)
>> are directly related to Go and computer Go.
>
>
> Thanks Ingo.
>
> In my talk I will focus on the source of AlphaGo's power: policy and value
> networks. I will also mention the status and conclusion of our investigation
> on AlphaGo's problem in the 4th game against Lee Sedol.
>
> Looking forward to meeting you all there.
>
> Regards,
> Aja
>
>>
>>
>> Ingo.
>> ___
>> 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] Creating the playout NN

[Michael Markefka]

I don't remember the content of the paper and currently can't look at the
PDF, but one possible explanation could be that a simple model trained
directly maybe regularizes differently from one trained on the best-fit
pre-smoothed output of a deeper net. The second could perhaps offer better
local optimization and regularization at higher accuracy with equal
parameter count.
Am 12.06.2016 13:05 schrieb "Álvaro Begué" :

> I don't understand the point of using the deeper network to train the
> shallower one. If you had enough data to be able to train a model with many
> parameters, you have enough to train a model with fewer parameters.
>
> Álvaro.
>
>
> On Sun, Jun 12, 2016 at 5:52 AM, Michael Markefka <
> michael.marke...@gmail.com> wrote:
>
>> Might be worthwhile to try the faster, shallower policy network as a
>> MCTS replacement if it were fast enough to support enough breadth.
>> Could cut down on some of the scoring variations that confuse rather
>> than inform the score expectation.
>>
>> On Sun, Jun 12, 2016 at 10:56 AM, Stefan Kaitschick
>>  wrote:
>> > I don't know how the added training compares to direct training of the
>> > shallow network.
>> > It's prob. not so important, because both should be much faster than the
>> > training of the deep NN.
>> > Accuracy should be slightly improved.
>> >
>> > Together, that might not justify the effort. But I think the fact that
>> you
>> > can create the mimicking NN, after the deep NN has been refined with
>> self
>> > play, is important.
>> >
>> > On Sun, Jun 12, 2016 at 9:51 AM, Petri Pitkanen <
>> petri.t.pitka...@gmail.com>
>> > wrote:
>> >>
>> >> Would the expected improvement be reduced training time or improved
>> >> accuracy?
>> >>
>> >>
>> >> 2016-06-11 23:06 GMT+03:00 Stefan Kaitschick
>> >> :
>> >>>
>> >>> If I understood it right, the playout NN in AlphaGo was created by
>> using
>> >>> the same training set as the one used for the large NN that is used
>> in the
>> >>> tree. There would be an alternative though. I don't know if this is
>> the best
>> >>> source, but here is one example: https://arxiv.org/pdf/1312.6184.pdf
>> >>> The idea is to teach a shallow NN to mimic the outputs of a deeper
>> net.
>> >>> For one thing, this seems to give better results than direct training
>> on the
>> >>> same set. But also, more importantly, this could be done after the
>> large NN
>> >>> has been improved with selfplay.
>> >>> And after that, the selfplay could be restarted with the new playout
>> NN.
>> >>> So it seems to me, there is real room for improvement here.
>> >>>
>> >>> Stefan
>> >>>
>> >>> ___
>> >>> 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
>> ___
>> 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] Creating the playout NN

[Michael Markefka]

Might be worthwhile to try the faster, shallower policy network as a
MCTS replacement if it were fast enough to support enough breadth.
Could cut down on some of the scoring variations that confuse rather
than inform the score expectation.

On Sun, Jun 12, 2016 at 10:56 AM, Stefan Kaitschick
 wrote:
> I don't know how the added training compares to direct training of the
> shallow network.
> It's prob. not so important, because both should be much faster than the
> training of the deep NN.
> Accuracy should be slightly improved.
>
> Together, that might not justify the effort. But I think the fact that you
> can create the mimicking NN, after the deep NN has been refined with self
> play, is important.
>
> On Sun, Jun 12, 2016 at 9:51 AM, Petri Pitkanen 
> wrote:
>>
>> Would the expected improvement be reduced training time or improved
>> accuracy?
>>
>>
>> 2016-06-11 23:06 GMT+03:00 Stefan Kaitschick
>> :
>>>
>>> If I understood it right, the playout NN in AlphaGo was created by using
>>> the same training set as the one used for the large NN that is used in the
>>> tree. There would be an alternative though. I don't know if this is the best
>>> source, but here is one example: https://arxiv.org/pdf/1312.6184.pdf
>>> The idea is to teach a shallow NN to mimic the outputs of a deeper net.
>>> For one thing, this seems to give better results than direct training on the
>>> same set. But also, more importantly, this could be done after the large NN
>>> has been improved with selfplay.
>>> And after that, the selfplay could be restarted with the new playout NN.
>>> So it seems to me, there is real room for improvement here.
>>>
>>> Stefan
>>>
>>> ___
>>> 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
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Hajin Lee will play a live commented game against CrazyStone

[Michael Markefka]

That is awesome! Looking forward to it!

On Mon, May 16, 2016 at 9:50 AM, Rémi Coulom  wrote:
> Hi,
>
> I am very happy to announce that Hajin Lee will play a live commented game 
> against Crazy Stone on Sunday, at 8PM Korean time. The game will take place 
> on KGS, and she will make live comments on her youtube channel.
>
> Haylee's youtube:
> https://www.youtube.com/c/HayleesWorldofGoBaduk
>
> 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] OmegaGo

[Michael Markefka]

Can I flag this as spam?

On Tue, Apr 19, 2016 at 11:23 PM, djhbrown .  wrote:
> 6D out of the blue is no mean achievement,...  60+ years ago, the
> market for gizmos in UK was flooded with cheap Japanese copies of
> European products; but whilst innovation and product quality
> improvement by European manufacturers faded as their fat cat owners
> complacently went cocacola-soaked soft,  Japanese industry, unlike its
> USA counterpart, was listening attentively to the wise words of
> W.Edwards Deming (eg [1,2]) and beginning to improve the reliability,
> efficiency and efficacy of its products, and by about 30 years ago,
> Japanese engineering was the equal or better of even German
> technology.
>
> Korean, Formosan and Hong Kong e-tigers followed hotfoot in Japan's
> footsteps, and now the same thing is happening in China, so we can
> expect to see a vast array of Shanghai-teenager-bedroom-produced
> shanghaied miniclones of Alpha, most with unimaginative copycat names
> like Beta, Eta, Theta, AIota etc, skulking around the corridors of the
> Internet, all of which will at first be cheap imitations, but sowing
> the seeds of in-house and inter-house R&D quality circles, so that
> their own descendants will before very long become to Californian IT
> as Japanese fuel-efficient reliable engines are to US unreliable
> gas-guzzlers.
>
> Watch out Google Cloud byte-guzzlers, teenage rebels with the lessons
> of Deming in their notebooks, who have learned from history and from
> the sterling modus operandi of Steve Jobs and Uncle Tom Cobley et al,
> are on their way up your Jacob's ladder...
>
> 1.  Charles A. Barclay (1993) Quality Strategy and TQM Policies:
> Empirical Evidence.
> MIR: Management International Review Vol. 33, Strategic Quality Management.
> 2.  
> http://asq.org/learn-about-quality/total-quality-management/overview/deming-points.html
>
>>> Anybody knows who is the author of BetaGo? It is playing with account
>>> GoBeta on KGS, and is 6d.
> ___
> 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] new challenge for Go programmers

[Michael Markefka]

Then again DNNs also manage feature extraction on unlabeled data with
increasing levels of abstraction towards upper layers. Perhaps one
could apply such a specifically trained DNN to artificial board
situations that emphasize specific concepts and examine the network's
activation, trying to map activation patterns to human Go concepts.

Still hard work, and questionable payoff, but just wanted to pitch
that in as idea.


> However, if someone was to do all the dirty work setting up all the
> infrastructure, hunt down the training data and then financially facilitate
> the thousands of hours of human work and the tens to hundreds of thousands
> of hours of automated learning work, I would become substantially more
> interested...and think a high quality desired outcome remains a low
> probability.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] computergo.org

[Michael Markefka]

Not a definite solution yet, but more of a call to action here: Would
anyone be interested contributing to a well-maintained computer go
news site? I would consider that a useful service that is currently
lacking. I'd be happy to contribute news articles and links.

On Thu, Mar 17, 2016 at 4:16 PM, Joshua Shriver  wrote:
> Does anyone have interest in that domain name? I'd be willing to
> transfer it to a new owner for free.  It came up a year or so back and
> I grabbed it just in case but never used it.
>
> Rather see it go to someone who can use it rather than squat. It's
> already for another year.
>
> -Josh
> ___
> 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] Deep Learning learning resources?

[Michael Markefka]

This online book by Michael Nielsen is a fantastic resource:
http://neuralnetworksanddeeplearning.com/

It builds everything from the ground up in easily digested chunks. All
the required math is in there, but can be skipped if just a general
understanding and basis for application is desired. Highly
recommended.

On Wed, Mar 2, 2016 at 10:53 AM, Darren Cook  wrote:
> I'm sure quite a few people here have suddenly taken a look at neural
> nets the past few months. With hindsight where have you learnt most?
> Which is the most useful book you've read? Is there a Udacity (or
> similar) course that you recommend? Or perhaps a blog or youtube series
> that was so good you went back and read/viewed all the archives?
>
> Thanks!
> Darren
>
> P.S. I was thinking pragmatic, and general, how-to guides for people
> dealing with challenging problems similar to computer go, but if you
> have recommendations for latest academic theories, or for a very
> specific field, I'm sure someone would appreciate hearing it.
> ___
> 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] Deep Zen - do we have a race now?

[Michael Markefka]

Hi Petr,

to clarify a bit:

pylearn2 specifically comes with a script to convert a model trained
on a GPU into a version that runs on the CPU. This doesn't work very
well though and the documentation points that out too. According to
the dev commens that is down to how Theano, the framework pylearn2 is
based on, handles its shared variables und the CUDA variables need to
be converted to Theano tensor variables.

Just wanted to advise caution that this process working flawlessly
isn't necessarily given in every NN lib. If Caffe does this well, then
David shouldn't have any problem of course and this warning doesn't
apply here.

-Michael

On Wed, Mar 2, 2016 at 8:57 AM, Petr Baudis  wrote:
> On Tue, Mar 01, 2016 at 02:51:03PM -0800, David Fotland wrote:
>> > Also, if you are training on a GPU you can probably avoid a lot of
>> > hassle if you expect to run it on a GPU as well. I don't know how other
>> > NN implementations handle it, but the GPU-to-CPU conversion script that
>> > comes with the Theano-based pylearn2 kit doesn't work very reliably.
>> I'll keep it in mind.  I'm using caffe, which has a compile-time flag, so 
>> I'm not sure it will work with GPU enabled on a machine without a GPU.
>
> I'm not sure about Michael's specific problem, but in my experience,
> there is no trouble at all transferring stuff between CPU and GPU - your
> model is, after all, just the weight matrices.  In Caffe, you should
> be able to switch between GPU and CPU completely freely.
>
> Petr Baudis
> ___
> 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] Deep Zen - do we have a race now?

[Michael Markefka]

Would be nice to have it as an option. My desktop PC and my laptop
both have CUDA-enabled graphics, and that isn't uncommon anymore.

Also, if you are training on a GPU you can probably avoid a lot of
hassle if you expect to run it on a GPU as well. I don't know how
other NN implementations handle it, but the GPU-to-CPU conversion
script that comes with the Theano-based pylearn2 kit doesn't work very
reliably.

Also, even quite big nets probably can be run on modest GPUs
reasonably well (within memory bounds). It's the training where the
size really hurts.

On Tue, Mar 1, 2016 at 6:19 PM, Petr Baudis  wrote:
> On Tue, Mar 01, 2016 at 09:14:39AM -0800, David Fotland wrote:
>> Very interesting, but it should also mention Aya.
>>
>> I'm working on this as well, but I haven’t bought any hardware yet.  My goal 
>> is not to get 7 dan on expensive hardware, but to get as much strength as I 
>> can on standard PC hardware.  I'll be looking at much smaller nets, that 
>> don’t need a GPU to run.  I'll have to buy a GPU for training.
>
> But I think most people who play Go are also fans of computer games that
> often do use GPUs. :-)  Of course, it's something totally different from
> NVidia Keplers, but still the step up from a CPU is tremendous.
>
> Petr Baudis
> ___
> 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] Move evalution by expected value, as product of expected winrate and expected points?

[Michael Markefka]

Hello everyone,

in the wake of AlphaGo using a DCNN to predict expected winrate of a
move, I've been wondering whether one could train a DCNN for expected
territory or points successfully enough to be of some use (leaving the
issue of win by resignation for a more in-depth discussion). And,
whether winrate and expected territory (or points) always run in
parallel or whether there are diverging moments.

Computer Go programs play what are considered slack or slow moves when
ahead, sometimes being too conservative and giving away too much of
their potential advantage. If expected points and expected winrate
diverge, this could be a way to make the programs play in a more
natural way, even if there were no strength increase to be gained.
Then again there might be a parameter configuration that might yield
some advantage and perhaps this configuration would need to be
dynamic, favoring winrate the further the game progresses.


As a general example for the idea, let's assume we have the following
potential moves generated by our program:

#1: Winrate 55%, +5 expected final points
#2: Winrate 53%, +15 expected final points

Is the move with higher winrate always better? Or would there be some
benefit to choosing #2? Would this differ depending on how far along
the game is?

If we knew the winrate prediction to be perfect, then going by that
alone would probably result in the best overall performance. But given
some uncertainty there, expected value could be interesting.


Any takers for some experiments?


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

Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search (value network)

[Michael Markefka]

That sounds like it'd be the MSE as classification error of the eventual result.

I'm currently not able to look at the paper, but couldn't you use a
softmax output layer with two nodes and take the probability
distribution as winrate?

On Thu, Feb 4, 2016 at 8:34 PM, Álvaro Begué  wrote:
> I am not sure how exactly they define MSE. If you look at the plot in figure
> 2b, the MSE at the very beginning of the game (where you can't possibly know
> anything about the result) is 0.50. That suggests it's something else than
> your [very sensible] interpretation.
>
> Álvaro.
>
>
>
> On Thu, Feb 4, 2016 at 2:24 PM, Detlef Schmicker  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> >> Since all positions of all games in the dataset are used, winrate
>> >> should distributes from 0% to 100%, or -1 to 1, not 1. Then, the
>> >> number 70% could be wrong.  MSE is 0.37 just means the average
>> >> error is about 0.6, I think.
>>
>> 0.6 in the range of -1 to 1,
>>
>> which means -1 (eg lost by b) games -> typical value -0.4
>> and +1 games -> typical value +0.4 of the value network
>>
>> if I rescale -1 to +1 to  0 - 100% (eg winrate for b) than I get about
>> 30% for games lost by b and 70% for games won by B?
>>
>> Detlef
>>
>>
>> Am 04.02.2016 um 20:10 schrieb Hideki Kato:
>> > Detlef Schmicker: <56b385ce.4080...@physik.de>: Hi,
>> >
>> > I try to reproduce numbers from section 3: training the value
>> > network
>> >
>> > On the test set of kgs games the MSE is 0.37. Is it correct, that
>> > the results are represented as +1 and -1?
>> >
>> >> Looks correct.
>> >
>> > This means, that in a typical board position you get a value of
>> > 1-sqrt(0.37) = 0.4  --> this would correspond to a win rate of 70%
>> > ?!
>> >
>> >> Since all positions of all games in the dataset are used, winrate
>> >> should distributes from 0% to 100%, or -1 to 1, not 1. Then, the
>> >> number 70% could be wrong.  MSE is 0.37 just means the average
>> >> error is about 0.6, I think.
>> >
>> >> Hideki
>> >
>> > Is it really true, that a typical kgs 6d+ position is judeged with
>> > such a high win rate (even though it it is overfitted, so the test
>> > set number is to bad!), or do I misinterpret the MSE calculation?!
>> >
>> > Any help would be great,
>> >
>> > Detlef
>> >
>> > Am 27.01.2016 um 19:46 schrieb Aja Huang:
>>  Hi all,
>> 
>>  We are very excited to announce that our Go program, AlphaGo,
>>  has beaten a professional player for the first time. AlphaGo
>>  beat the European champion Fan Hui by 5 games to 0. We hope
>>  you enjoy our paper, published in Nature today. The paper and
>>  all the games can be found here:
>> 
>>  http://www.deepmind.com/alpha-go.html
>> 
>>  AlphaGo will be competing in a match against Lee Sedol in
>>  Seoul, this March, to see whether we finally have a Go
>>  program that is stronger than any human!
>> 
>>  Aja
>> 
>>  PS I am very busy preparing AlphaGo for the match, so
>>  apologies in advance if I cannot respond to all questions
>>  about AlphaGo.
>> 
>> 
>> 
>>  ___ 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
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.22 (GNU/Linux)
>>
>> iQIcBAEBAgAGBQJWs6WFAAoJEInWdHg+Znf4eTsP/21vawWsmrZkDuAjTkwbKB2S
>> 7LpLi3huuLlepkulmUr3rIUvDHhTOwD04pDHjjVrIDBB1k3JjQQ/YKWDfijQQYu6
>> ZI1GK55pglUPH+uc+rxfM89ziJwCQrza71l5XU+5ffcBwxRjeAL+D1fGGyr0CPlv
>> WKR/Q07XDslXhwlk2O6NDpd80d38dMlMV9lO4s8Zf3Y+o8WJOuyEdybRpg8VOibq
>> o59RCAWUiVkTs++iSihcIrVAwGnLtkPyMJ/lBN6zMyZQeuM0dyYL+IAoMH9IdCLQ
>> 0jpbtJEqtSsp1ZjWs9s/M4pxKlvUZLThtYSjyGDJ2qDYXII6DeBgxHGUoUxc5A6a
>> HVF04gG77U2fMCa/6eGlQN2380kNCjdyRCDUZc9St3tbQPnWU+syk6U/inF7bhAA
>> 7ONJD0dcjZROmblqurv32pO6sLuS8wA4DfJhpM5xSSJcYI46YQtVWL4OXY+dtx6S
>> 6uQ1fiPqgo4WM0iHEOnh7BEz0NqZeahIUJJVmgKODzp2krOqbpOpbwe7WUI7UHmK
>> 3LCNC9oMRybNuc+jrbHqFwT+tgQLTqpbHZuDVzKkBcxqPSj7hRvjLXAjkWNCzL7j
>> Yo4MySS6rzenuj9ZRSrQDSYfowRZyzPzMnmjkMbM7R7wpR5CL4U95LqOdMnce2IG
>> s/6iYcuUH8KqpG9NMy0U
>> =TnKW
>> -END PGP SIGNATURE-
>> ___
>> 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] Zen19X achieved stable KGS 7d

[Michael Markefka]

On Mon, Feb 1, 2016 at 1:44 PM, Hideki Kato  wrote:
> I was, btw, really surprised when Zen beat fj with two stones
> handi.
> http://files.gokgs.com/games/2016/1/31/Zen19X-fj.sgf
>
> Hideki

On the DGoB forums fj stated, possibly in jest, that this was an even
game, as he had had a glass of wine for every stone of handicap there.
Seems like he wasn't in the most competitive of moods. Still a good
game though. :)
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search

[Michael Markefka]

On Mon, Feb 1, 2016 at 10:19 AM, Darren Cook  wrote:
> It seems [1] the smart money might be on Lee Sedol:

In the DeepMind press conferences (
https://www.youtube.com/watch?v=yR017hmUSC4 -
https://www.youtube.com/watch?v=_r3yF4lV0wk ) Demis Hassabis stated,
that he was quietly confident.

I assume that means they've got a version up and running that at least
matches Lee Sedol's Elo rating, perhaps even slightly exceeding it.
They might be wary of the engine displaying some idiosyncracy they
haven't picked up on yet, which Sedol might notice and then exploit.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Computer-go Digest, Vol 72, Issue 41

[Michael Markefka]

I agree.

It might be interesting to set this up a while after the Lee Sedol
matches if Ke Jie still holds the #1 spot at at that time. After
beating the best player of the past ten years, beating the currently
best player would in a way complete AlphaGo's victory over current
human Go ability.

On Mon, Feb 1, 2016 at 4:04 AM, Marc Landgraf  wrote:
> Why would they water down their Lee Sedol game by announcing another
> game before their big game has even happened? No matter if that game
> would be before or after.
> Sounds like an awful PR strategy.
>
> 2016-02-01 2:51 GMT+01:00 uurtamo . :
>> It might even be interesting if it took place *before* the lee sedol match.
>>
>> s.
>>
>> On Jan 31, 2016 5:09 PM, "Chaohao Pan"  wrote:
>>>
>>> Just in case that no one knows it. Ke Jie has publicly announced that he
>>> is willing to play against AlphaGo, even without any prize money. Since Ke
>>> Jie is absolutely the current No.1, it would be a good choice to have
>>> another match with Ke Jie, time permitting, no matter AlphaGo wins or loses
>>> against Lee Sedol,.
>>>
>>> Chaohao
>>>
>>> 2016-01-31 13:34 GMT-08:00 John Tromp :

 > You must be kidding about Lee Sedol.
 > ...
 > So he was by far the biggest fish Google could ever catch for that
 > game, for Go insiders as well as for people outside the Go scene.

 Well said, Marc.

 In terms of name recognition and domination in the past decade,
 who else but Lee Sedol should be picked as the "Kasparov of Go"
 in the ultimate Man vs Machine match?

 -John
 ___
 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
> ___
> 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] Mastering the Game of Go with Deep Neural Networks and Tree Search

[Michael Markefka]

On Thu, Jan 28, 2016 at 3:14 PM, Stefan Kaitschick
 wrote:

> That "value network" is just amazing to me.
> It does what computer go failed at for over 20 years, and what MCTS was
> designed to sidestep.

Thought it worth a mention: Detlef posted about trying to train a CNN
on win rate as well in February. So it seems he was onto something
there.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Game Over

[Michael Markefka]

That would make my writing nonsense of course. :)

Thanks for the pointer.

On Thu, Jan 28, 2016 at 12:26 PM, Xavier Combelle
 wrote:
>
>
> 2016-01-28 12:23 GMT+01:00 Michael Markefka :
>>
>> I find it interesting that right until he ends his review, Antti only
>> praises White's moves, which are the human ones. When he stops, he
>> even considers a win by White as basically inevitable.
>>
> White moves are the AI ones, check the players
>
>
> ___
> 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] Mastering the Game of Go with Deep Neural Networks and Tree Search

[Michael Markefka]

I think many amateurs would already benefit from a simple blunder
check and a short list of viable alternatives and short continuations
for every move.

If I could leave my PC running over night for a 30s/move analysis at
9d level and then walk through my game with that quality of analysis,
I'd be more than satisfied.


On Thu, Jan 28, 2016 at 7:42 AM, Robert Jasiek  wrote:
> Congratulations to the researchers!
>
> On 27.01.2016 21:10, Michael Markefka wrote:
>>
>> I really do hope that this also turns into a good analysis and
>> teaching tool for human player. That would be a fantastic benefit from
>> this advancement in computer Go.
>
>
> The programs successful as computer players mostly rely on computation power
> for learning and decision-making. This can be used for teaching tools that
> do not need to provide text explanations and other reasoning to the human
> pupils: computer game opponent, life and death playing opponent, empirical
> winning percentages of patterns etc.
>
> Currently such programs do not provide sophisticated explanations and
> reasoning about tactical decision-making, strategy and positional judgement
> fitting human players' / pupils' conceptual thinking.
>
> If always correct teaching is not the aim (but if a computer teacher may err
> as much as a human teacher errs), in principle it should be possible to
> combine the successful means of using computation power with the reasonably
> accurate human descriptions of sophisticated explanations and reasoning.
> This requires implementation of expert system knowledge adapted from the
> best (the least ambiguous, the most often correct / applicable) descriptions
> of human-understandable go theory and further research in the latter.
>
> --
> robert jasiek
>
> ___
> 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] Game Over

[Michael Markefka]

I find it interesting that right until he ends his review, Antti only
praises White's moves, which are the human ones. When he stops, he
even considers a win by White as basically inevitable.

Now Fan Hui either blundered badly afterwards, or more promising, it
could be hard for humans to evaluate AlphaGo's play at this point
because they undervalue some it its choices. Which of course would be
similar to how some moves by the first world-beating chess AIs have
been treated by human experts.

AlphaGo might be even more of a wild card than it seems.


Also, on another note, that Google set up those Sedol games makes me
assume that they are convinced of actually succeeding. The Fan Hui
matches have been months ago, and AlphaGo will have spent that time
learning, and when the matches come around they will probably throw A
LOT of processing power at Sedol. I don't think they would try for so
much public reach to then fail and be associated with failure and
hybris.

On Thu, Jan 28, 2016 at 12:12 PM, J. van der Steen
 wrote:
>
> Hi Xavier,
>
> Really nice comments by Antti Törmänen, to the point and very clear
> explanation. Thanks for the pointer.
>
> best regards,
> Jan van der Steen
>
> On 28-01-16 11:45, Xavier Combelle wrote:
>>
>> here a comment by Antti Törmänen
>>
>> http://gooften.net/2016/01/28/the-future-is-here-a-professional-level-go-ai/
>>
>> 2016-01-28 11:19 GMT+01:00 Darren Cook > >:
>>
>> > If you want to view them in the browser, I've also put them on my
>> blog:
>>
>> >http://www.furidamu.org/blog/2016/01/26/mastering-the-game-of-go-with-deep-neural-networks-and-tree-search/
>> > (scroll down)
>>
>> Thanks. Has anyone (strong) made commented versions yet? I played
>> through the first game, but it just looks like a game between two
>> players much stronger than me :-)
>>
>> (Ingo, are you analyzing them with e.g. CrazyStone? Is there a
>> particular point where it adjusts who it thinks is winning?)
>>
>> 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
>>
> ___
> 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] Mastering the Game of Go with Deep Neural Networks and Tree Search

[Michael Markefka]

I really do hope that this also turns into a good analysis and
teaching tool for human player. That would be a fantastic benefit from
this advancement in computer Go.

On Wed, Jan 27, 2016 at 9:08 PM, Aja Huang  wrote:
> 2016-01-27 18:46 GMT+00:00 Aja Huang :
>>
>> Hi all,
>>
>> We are very excited to announce that our Go program, AlphaGo, has beaten a
>> professional player for the first time. AlphaGo beat the European champion
>> Fan Hui by 5 games to 0. We hope you enjoy our paper, published in Nature
>> today. The paper and all the games can be found here:
>>
>> http://www.deepmind.com/alpha-go.html
>
>
> The paper is freely available to download at the bottom of the page.
> https://storage.googleapis.com/deepmind-data/assets/papers/deepmind-mastering-go.pdf
>
> Aja
>
>>
>> AlphaGo will be competing in a match against Lee Sedol in Seoul, this
>> March, to see whether we finally have a Go program that is stronger than any
>> human!
>>
>> Aja
>>
>> PS I am very busy preparing AlphaGo for the match, so apologies in advance
>> if I cannot respond to all questions about AlphaGo.
>>
>> ___
>> 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] CNN with 54% prediction on KGS 6d+ data

[Michael Markefka]

I think ko moves are taken into account on one of in the input planes
for most configurations. At least I hope remember that correctly.
Could it be achieved to create such a plane from the prior input
matrix and following output matrix by difference?

On Wed, Dec 9, 2015 at 2:08 PM, Igor Polyakov
 wrote:
> I doubt that the illegal moves would fall away since every professional
> would retake the ko... if it was legal
>
>
> On 2015-12-09 4:59, Michael Markefka wrote:
>>
>> Thank you for the feedback, everyone.
>>
>>
>> Regarding the CPU-GPU roundtrips, I'm wondering whether it'd be
>> possible to recursively apply the output matrix to the prior input
>> matrix to update board positions within the GPU and  without any
>> actual (possibly CPU-based) evaluation until all branches come up with
>> game ending states. I assume illegal moves would mostly fall away when
>> sticking to the top ten or top five move considerations provided by
>> the CNN.
>>
>> As for performance, I could imagine initialization being relatively
>> slow, but wouldn't be surprised if the GPU-based CNN performance could
>> offer a branch size, running through many parallel boards with
>> comparatively minor performance impact, where this outweighed the
>> initial overhead again.
>>
>> Whether this would provide a better evaluation function than MCTS I
>> don't know, but just like Alvaro I would love to see this tried, even
>> if just to rule it out for the moment.
>>
>>
>> I've got a GTX 980 Ti on a 4790k with 16 GB at home. For a low key
>> test I could run Windows (CUDA installed and running, tested with
>> pylearn2) or Ubuntu from a live setup on USB and would be willing to
>> run test code, if somebody provided a package I could simply download
>> and execute.
>>
>>
>> All the best
>>
>> Michael
>>
>>
>> On Tue, Dec 8, 2015 at 7:52 PM, Álvaro Begué 
>> wrote:
>>>
>>> Of course whether these "neuro-playouts" are any better than the heavy
>>> playouts currently being used by strong programs is an empirical
>>> question.
>>> But I would love to see it answered...
>>>
>>>
>>>
>>> On Tue, Dec 8, 2015 at 1:31 PM, David Ongaro 
>>> wrote:
>>>>
>>>> Did everyone forget the fact that stronger playouts don't necessarily
>>>> lead
>>>> to an better evaluation function? (Yes, that what playouts essential
>>>> are, a
>>>> dynamic evaluation function.) This is even under the assumption that we
>>>> can
>>>> reach the same number of playouts per move.
>>>>
>>>>
>>>> On 08 Dec 2015, at 10:21, Álvaro Begué  wrote:
>>>>
>>>> I don't think the CPU-GPU communication is what's going to kill this
>>>> idea.
>>>> The latency in actually computing the feed-forward pass of the CNN is
>>>> going
>>>> to be in the order of 0.1 seconds (I am guessing here), which means
>>>> finishing the first playout will take many seconds.
>>>>
>>>> So perhaps it would be interesting to do something like this for
>>>> correspondence games, but not for regular games.
>>>>
>>>>
>>>> Álvaro.
>>>>
>>>>
>>>>
>>>> On Tue, Dec 8, 2015 at 12:03 PM, Petr Baudis  wrote:
>>>>>
>>>>>Hi!
>>>>>
>>>>>Well, for this to be practical the entire playout would have to be
>>>>> executed on the GPU, with no round-trips to the CPU.  That's what my
>>>>> email was aimed at.
>>>>>
>>>>> On Tue, Dec 08, 2015 at 04:37:05PM +, Josef Moudrik wrote:
>>>>>>
>>>>>> Regarding full CNN playouts, I think that problem is that a playout is
>>>>>> a
>>>>>> long serial process, given 200-300 moves a game. You need to construct
>>>>>> planes and transfer them to GPU for each move and read result back (at
>>>>>> least with current CNN implementations afaik), so my guess would be
>>>>>> that
>>>>>> such playout would take time in order of seconds. So there seems to be
>>>>>> a
>>>>>> tradeoff, CNN playouts are (probably much) better (at "playing better
>>>>>> games") than e.g. distribution playouts, but whether this is worth the
>>>>>> implied (probably much) l

Re: [Computer-go] CNN with 54% prediction on KGS 6d+ data

[Michael Markefka]

Thank you for the feedback, everyone.


Regarding the CPU-GPU roundtrips, I'm wondering whether it'd be
possible to recursively apply the output matrix to the prior input
matrix to update board positions within the GPU and  without any
actual (possibly CPU-based) evaluation until all branches come up with
game ending states. I assume illegal moves would mostly fall away when
sticking to the top ten or top five move considerations provided by
the CNN.

As for performance, I could imagine initialization being relatively
slow, but wouldn't be surprised if the GPU-based CNN performance could
offer a branch size, running through many parallel boards with
comparatively minor performance impact, where this outweighed the
initial overhead again.

Whether this would provide a better evaluation function than MCTS I
don't know, but just like Alvaro I would love to see this tried, even
if just to rule it out for the moment.


I've got a GTX 980 Ti on a 4790k with 16 GB at home. For a low key
test I could run Windows (CUDA installed and running, tested with
pylearn2) or Ubuntu from a live setup on USB and would be willing to
run test code, if somebody provided a package I could simply download
and execute.


All the best

Michael


On Tue, Dec 8, 2015 at 7:52 PM, Álvaro Begué  wrote:
> Of course whether these "neuro-playouts" are any better than the heavy
> playouts currently being used by strong programs is an empirical question.
> But I would love to see it answered...
>
>
>
> On Tue, Dec 8, 2015 at 1:31 PM, David Ongaro 
> wrote:
>>
>> Did everyone forget the fact that stronger playouts don't necessarily lead
>> to an better evaluation function? (Yes, that what playouts essential are, a
>> dynamic evaluation function.) This is even under the assumption that we can
>> reach the same number of playouts per move.
>>
>>
>> On 08 Dec 2015, at 10:21, Álvaro Begué  wrote:
>>
>> I don't think the CPU-GPU communication is what's going to kill this idea.
>> The latency in actually computing the feed-forward pass of the CNN is going
>> to be in the order of 0.1 seconds (I am guessing here), which means
>> finishing the first playout will take many seconds.
>>
>> So perhaps it would be interesting to do something like this for
>> correspondence games, but not for regular games.
>>
>>
>> Álvaro.
>>
>>
>>
>> On Tue, Dec 8, 2015 at 12:03 PM, Petr Baudis  wrote:
>>>
>>>   Hi!
>>>
>>>   Well, for this to be practical the entire playout would have to be
>>> executed on the GPU, with no round-trips to the CPU.  That's what my
>>> email was aimed at.
>>>
>>> On Tue, Dec 08, 2015 at 04:37:05PM +, Josef Moudrik wrote:
>>> > Regarding full CNN playouts, I think that problem is that a playout is
>>> > a
>>> > long serial process, given 200-300 moves a game. You need to construct
>>> > planes and transfer them to GPU for each move and read result back (at
>>> > least with current CNN implementations afaik), so my guess would be
>>> > that
>>> > such playout would take time in order of seconds. So there seems to be
>>> > a
>>> > tradeoff, CNN playouts are (probably much) better (at "playing better
>>> > games") than e.g. distribution playouts, but whether this is worth the
>>> > implied (probably much) lower height of the MC tree is a question.
>>> >
>>> > Maybe if you had really a lot of GPUs and very high thinking time, this
>>> > could be the way.
>>> >
>>> > Josef
>>> >
>>> > On Tue, Dec 8, 2015 at 5:17 PM Petr Baudis  wrote:
>>> >
>>> > >   Hi!
>>> > >
>>> > >   In case someone is looking for a starting point to actually
>>> > > implement
>>> > > Go rules etc. on GPU, you may find useful:
>>> > >
>>> > >
>>> > >
>>> > > https://www.mail-archive.com/computer-go@computer-go.org/msg12485.html
>>> > >
>>> > >   I wonder if you can easily integrate caffe GPU kernels in another
>>> > > GPU
>>> > > kernel like this?  But without training, reimplementing the NN could
>>> > > be
>>> > > pretty straightforward.
>>> > >
>>> > > On Tue, Dec 08, 2015 at 04:53:14PM +0100, Michael Markefka wrote:
>>> > > > Hello Detlef,
>>> > > >
>>> > > > I've got a question regarding CNN-based Go engines I couldn't find
>>>

Re: [Computer-go] CNN with 54% prediction on KGS 6d+ data

[Michael Markefka]

Hello Detlef,

I've got a question regarding CNN-based Go engines I couldn't find
anything about on this list. As I've been following your posts here, I
thought you might be the right person to ask.

Have you ever tried using the CNN for complete playouts? I know that
CNNs have been tried for move prediction, immediate scoring and move
generation to be used in an MC evaluator, but couldn't find anything
about CNN-based playouts.

It might only be feasible to play out the CNN's first choice move for
evaluation purposes, but considering how well the performance of batch
sizes scales, especially on GPU-based CNN applications, it might be
possible to setup something like 10 candidate moves, 10 reply
candidate moves and then have the CNN play out the first choice move
for those 100 board positions until the end and then sum up scores
again for move evaluation (and/or possibly apply some other tried and
tested methods like minimax). Given that the number of 10 moves is
supposed to be illustrative rather than representative, other
configurations of depth and width in position generation and
evaluation would be possible.

It feels like CNN can provide a very focused, high-quality width in
move generation, but it might also be possible to apply that quality
to depth of evaluation.

Any thoughts to share?


All the best

Michael

On Tue, Dec 8, 2015 at 4:13 PM, Detlef Schmicker  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> as somebody ask I will offer my actual CNN for testing.
>
> It has 54% prediction on KGS 6d+ data (which I thought would be state
> of the art when I started training, but it is not anymore:).
>
> it has:
> 1
> 2
> 3
>> 4 libs playing color
> 1
> 2
> 3
>> 4 libs opponent color
> Empty points
> last move
> second last move
> third last move
> forth last move
>
> input layers, and it is fully convolutional, so with just editing the
> golast19.prototxt file you can use it for 13x13 as well, as I did on
> last sunday. It was used in November tournament as well.
>
> You can find it
> http://physik.de/CNNlast.tar.gz
>
>
>
> If you try here some points I like to get discussion:
>
> - - it seems to me, that the playouts get much more important with such
> a strong move prediction. Often the move prediction seems better the
> playouts (I use 8000 at the moment against pachi 32000 with about 70%
> winrate on 19x19, but with an extremely focused progressive widening
> (a=400, a=20 was usual).
>
> - - live and death becomes worse. My interpretation is, that the strong
> CNN does not play moves, which obviously do not help to get a group
> life, but would help the playouts to recognize the group is dead.
> (http://physik.de/example.sgf top black group was with weaker move
> prediction read very dead, with good CNN it was 30% alive or so :(
>
>
> OK, hope you try it, as you know our engine oakfoam is open source :)
> We just merged all the CNN stuff into the main branch!
> https://bitbucket.org/francoisvn/oakfoam/wiki/Home
> http://oakfoam.com
>
>
> Do the very best with the CNN
>
> Detlef
>
>
>
>
> code:
> if (col==Go::BLACK) {
>   for (int j=0;j for (int k=0;k   {
> for (int l=0;l data[l*size*size+size*j+k]=0;
> //fprintf(stderr,"%d %d %d\n",i,j,k);
> int pos=Go::Position::xy2pos(j,k,size);
> int libs=0;
> if (board->inGroup(pos))
> libs=board->getGroup(pos)->numRealLibs()-1;
> if (libs>3) libs=3;
> if (board->getColor(pos)==Go::BLACK)
>   {
>   data[(0+libs)*size*size + size*j + k]=1.0;
>   //data[size*size+size*j+k]=0.0;
>   }
>   else if (board->getColor(pos)==Go::WHITE)
>   {
>   //data[j*size+k]=0.0;
>   data[(4+libs)*size*size + size*j + k]=1.0;
>   }
>   else if
> (board->getColor(Go::Position::xy2pos(j,k,size))==Go::EMPTY)
>   {
> data[8*size*size + size*j + k]=1.0;
>   }
> }
> }
> if (col==Go::WHITE) {
>   for (int j=0;j for (int k=0;k   {//fprintf(stderr,"%d %d %d\n",i,j,k);
> for (int l=0;l data[l*size*size+size*j+k]=0;
> //fprintf(stderr,"%d %d %d\n",i,j,k);
> int pos=Go::Position::xy2pos(j,k,size);
> int libs=0;
> if (board->inGroup(pos))
> libs=board->getGroup(pos)->numRealLibs()-1;
> if (libs>3) libs=3;
> if (board->getColor(pos)==Go::BLACK)
>   {
>   data[(4+libs)*size*size + size*j + k]=1.0;
>   //data[size*size+size*j+k]=0.0;
>   }
>   else if (board->getColor(pos)==Go::WHITE)
>   {
>   //data[j*size+k]=0.0;
>   data[(0+libs)*size*s

Re: [Computer-go] Standalone DNN player support

[Michael Markefka]

I would love to have something like this.


I would appreciate some way to configure depth levels and variable
branching factors for move generation as well as scoring playouts
using the NN.

Regards,
Michael

On Wed, Apr 29, 2015 at 3:37 PM, Josef Moudrik  wrote:
> Hi!
>
> I am playing around with DNN move prediction (as everyone here seems to be
> doing at the moment) and I wonder what tools do you use to wrap the net to
> play correctly & support GTP. If there is no such wrapper, I am planning to
> write it myself (which should be fairly easy). I would like to hear your
> opinions on the matter; is anyone else interested in this?
>
> Some possible features:
>  - interface for DeepCL nets, caffe nets (as in the 25x25 experiment
> thread), ..
>  - GTP
>  - move correctness checking (is an issue?)
>  - pass implementation (maybe use GnuGo as an pass-oracle?)
>  - something else?
>
> Regards,
> Josef
>
> ___
> 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] Fwd: Teaching Deep Convolutional Neural Networks to Play Go

[Michael Markefka]

I was thinking about bootstrapping possibilities, and wondered whether
it would be possible to use a shallower mimic net for positional
evaluation playouts from a specific depth on after having generated
positions with a certain branching factor that typically allows the
actual pro move to be included, hopefully finding even stronger moves,
which then are fed back as targets for the primary function/net.
Perhaps even apply different amounts of shallowness in mimic function
NN configuration as well as depth/branching for move tree generation.

No idea if there are kind of depth/branching configurations that would
make sense or seem promising, given the existing hardware options.

On Sun, Mar 15, 2015 at 2:56 AM, Hugh Perkins  wrote:
> To be honest, what I really want is for it to self-learn, like David
> Silver's TreeStrap did for chess, but on the one hand I guess I should
> start by reproducing the existent, and on the other hand if we need
> millions of moves to train the net, that's going to make for very slow
> self-play...  Also, David Silver was associated with Aja Huang's
> paper, and I'm guessing therefore that it is very non-trivial to do,
> otherwise David Silver would have done it already :-)
> ___
> 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] UEC cup about to start

[Michael Markefka]

I hope DolBaram has a good showing this year. Probably the most
promising contender gunning for Zen and CrazyStone.

On Fri, Mar 13, 2015 at 8:32 PM, Martin Mueller  wrote:
> The 8th UEC Cup will start in a few hours. The top two programs get to play
> Cho Chikun on the 17th of March in Densei-sen.
>
> http://jsb.cs.uec.ac.jp/~igo/eng/
> http://jsb.cs.uec.ac.jp/~igo/eng/participant.html
>
> http://entcog.c.ooco.jp/entcog/densei/
> (Only this Japanese version is current for Densei-sen)
>
> I am not on site this year but I am hoping some of the participants will
> keep us up to date.
>
> Martin
>
>
> ___
> 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] [EMAIL PROTECTED]

[Michael Markefka]

Brilliant! Thank you, both of you, Peter and Claus!

-Mike

Claus Reinke wrote:
Now, for the technical matter: Could somebody please point me to a  quick rundown of how modern 
Go engines exactly utilize multicore  environments and the workload is segregated and 
distributed? I  don't have any significant knowledge on that, so any pointers would  be much 
appreciated.



Here's a start:
http://hal.inria.fr/docs/00/28/78/67/PDF/icin08.pdf
Gelly et al, The Parallelization of Monte-Carlo Planning


A couple more references here:

Group: computer-go - with tag parallelization
http://www.citeulike.org/group/5884/tag/parallelization

Claus




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



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

Re: [computer-go] Congratulations to David Fotland!

[Michael Markefka]

Hideki Kato wrote:

Don Dailey: <[EMAIL PROTECTED]>:

On Thu, 2008-10-02 at 19:17 +0200, Michael Markefka wrote:
So, when are we going to see distributed computing? [EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to increased 
processing capacity, imagine facilitating a few thousand PCs to do the 
computing. For good measure, [EMAIL PROTECTED] as about 800,000 nodes online as 
of now.

This subject keeps coming up - but it's not a good application at all
for this type of thing.   I think if you read the instructions on how to
do this you will see that it's extremely impractical for a go program.  


Imagine trying to build an interactive chess or go program on an
incredibly slow network and you will get the picture.   Imagine the
network is something like using email to communicate.   


The [EMAIL PROTECTED] type of stuff is based on a bunch of machines being able
to go off and do a work unsupervised - and basically communicating with
a single centralized process somewhere - very infrequently.  


It might be possible to build a huge cooperating go program network but
I believe it would require building our own system - and it would be far
from trivial.   It would have to be designed in an extremely fault
tolerant way too.


You and David is right in general.  @home type systems are 
good for larger problems without realtimeness.  However, I'd like to 
say it is possible to use such sysytem for computer-go tournament and 
it is not necessary to build my own system.  I'm now at Beijing and 
using a quad-core pc with two Playstation 3 (PS3) consoles connected 
together via a Gigabit Ethernet lan.  One PS3 increases simulations 
about 10% on 9x9 with current not-optimized-for-Cell implementatiion.  
The program running on PS3 Linux is just a simple and small 
application.


The long communication time via Internet will really decrease 
performance of UCT but for larger boards and with much heavier 
playouts that I will use, thousands or more PS3s will be helpful.


Hideki


- Don


Those are kind of the lines I've been thinking along. Go might not be 
the ideal application for distributed computing, but as long as there 
_are_ gains to be exploited, it might be worth the trouble. I've looked 
over the Gelly paper linked by Peter and it seems like indeed there 
could be gains and further optimizations to benefit from. (It's 12.30am 
here now though, so I'll leave the proper read through for tomorrow and 
continue then.) Shooting a football isn't the ideal way to kill 
somebody, but when I shoot half a million footballs at him, I just might 
club him to death.


Another thing: All those theoretical considerations aside, have there 
been ANY large scale tests? Even the Gelly paper admitted to not being 
able to run large-scale tests. Perhaps something worthwhile would crop 
up when actually trying? Great things have been stumbled upon by 
accident in the past. :)

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

Re: [computer-go] [EMAIL PROTECTED]

[Michael Markefka]

I think I'll respond here as not to further detract from David 
congratulory thread. :)
While not addressing the replies separately, rest assured that I've read 
them all.


Quickly picking up on what Claus wrote here, I agree that there might be 
some kind of "prestige angle" to exploit to get some 
support/funding/sponsoring. More specifically I've been thinking about 
the PS3, which already has a [EMAIL PROTECTED] client for example, as Sony 
might be receptive to pitching a "PS3 dominating the last bastion of 
human processing through its distributed awesomeness" narrative. It's a 
Japanese company, they have a huge installed hardware base and they 
could easily streamline distribution and maintenance of the distributed 
software infrastructure.


Now, for the technical matter: Could somebody please point me to a quick 
rundown of how modern Go engines exactly utilize multicore environments 
and the workload is segregated and distributed? I don't have any 
significant knowledge on that, so any pointers would be much appreciated.


I understand that there's a huge difference between having a dedicated 
multicore system or a close high-bandwidth network and some WAN 
distributed computing, but how much leeway is there to optimize Go 
calculations towards wide-area networking? Expecting usable processing 
and response times, the data chunks of course will shrink while overhead 
increases, but is there a sweet spot, where it could escape the 
silly-window-syndrome while retaining appreciable scalability?


The nitty-gritty metrics on how the engines handle the workload would be 
really interesting. This could also help approximate where potential 
chokepoints in the feasibility of grid computing GO are and whether some 
of them can be broken and remedied.


Apologies if this actually has been discussed to death before, but I 
just can't resist indulging my curiosity.


Regards,
Mike


Claus Reinke wrote:

But for grids (instead of clusters), the communication will become much much
bigger - I'd like to study that carefully one day, I have no clear idea of what 
is possible.

A trouble is that on grids (at least the ones I've seen) there are often
faults. We'll have to be fault tolerant I guess.


I've been somewhat on the fence for grids, but that is mainly because
computer scientists are at least as intelligent as Monte-Carlo playouts:
if adding "grid" to a project increases its chances of getting funding,
then "grid" will be added to the project, no matter how; and for a while,
that was exactly what happened - "grid this" and "grid that" everywhere..

However, while browsing papers like

"Toward Third Generation Internet Desktop Grids"
http://hal.inria.fr/inria-00148923/en/

isn't quite as fascinating as reading about the newest Go programming
techniques, it doesn't sound entirely hopeless, either. And isn't INRIA
nearby for some of you? If not, I'm sure that some funding agency in
your neighbourhood decided to steer research toward grid research
long ago;-)

Perhaps some of you Go engine authors could give some of those
Grid researchers a challenge - they have the hardware, the software,
and the need to research grid issues to justify their funding.

And you have the application that might be able to use all that. Unless
they think that their tools can't handle your requirements, they should be
quite interested in participating in your publicity ("beyond blue gene",
"the final man-machine intelligence challenge", and all that;-), not to
mention demonstrating that their tools can handle well-known-to-
be-tough problems. The genuine researchers among them will even
want to figure out how to address the research issues you raise.

Since netlag has been an issue even for slow human games over
internet servers, I'm sure it is going to be an issue here. But that
doesn't mean it is going to be insurmountable (as long as the
whole grid doesn't sit behind the same microwave transmitter;-).

Claus





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



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

Re: [computer-go] Congratulations to David Fotland!

[Michael Markefka]

So, when are we going to see distributed computing? [EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED] With Go engines that scale well to increased 
processing capacity, imagine facilitating a few thousand PCs to do the 
computing. For good measure, [EMAIL PROTECTED] as about 800,000 nodes online as 
of now.


What's the approximate increase in playing level per increase in 
processing power? Any rough law for that?


Best regards,
Mike


Olivier Teytaud wrote:
Mogo was allowed to use 800 cores, not more, and only for games against 
humans.
We have no acces to so many cores for computer-computer games (if there 
were only three teams involved,

we could :-) ).
For some games Huygens was unaivalable at all, and mogo played with much 
weaker hardware (some quad-cores,

however, it is not so bad :-) ).

Best regards,
Olivier




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


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