[computer-go] re: Fuego

[Martin Mueller]

Hello all,

as Rémi has pointed out, we have decided to make our Monte-Carlo Tree  
Search based program available as open source with an LGPL licence.  
This program, now called Fuego, has evolved from the Explorer source  
code. The current distribution contains a game-independent kernel, a  
Go-specific module and the player. It also includes several simple  
players, such as "average", which also plays on CGOS.


I would like to invite everyone to make contributions to this project  
and create the strongest Go program in the world :)

http://fuego.sourceforge.net/
http://cgos.boardspace.net/9x9/cross/Fuego-131-8c.html
http://www.lri.fr/~teytaud/cross/Fuego-225-8c.html

	Martin Müller, for the computer Go group at the University of  
Alberta, Edmonton, Canada___

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

[computer-go] gnugo3.7.10_10bis on 19x19 CGOS

[Martin Mueller]

This is a message for whoever is running gnugo3.7.10_10bis on 19x19  
CGOS.


This program does not seem to finish the games under CGOS rules  
correctly. I believe you need to set options such as

--mode gtp --chinese-rules --capture-all-dead

For example, look at game 37209.sgf against "ordinary" gnugo3.7.10_10.  
The program "lost" by 1.5, but if it captured the dead stones it would  
win.


Thank you

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

[computer-go] re: Fuego

[Martin Mueller]

Is this game independent kernel also used for Alberta's general game
playing entry?


No. We have programs for Go (several), Hex and Amazons that use it.

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

[computer-go] Seki in playouts

[Martin Mueller]

I
did not realize that his program, even with a large tree, would not be
able to recognize the seki.  I knew of course that the original Mogo
playouts had this problem, but I thought all strong programs had
solved it by now...


Hello Erik,

seki in playouts is still an unsolved problem for Fuego as well. I  
have tried many times to fix it by disabling selfatari moves. But  
anything I tried made the program measurably weaker overall.


Martin

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

[computer-go] re-CGT approximating the sum of subgames

[Martin Mueller]

I've been looking into CGT lately and I stumbled on some articles  
about approximating strategies for determining the sum of subgames  
(Thermostrat, MixedStrat, HotStrat etc.)
It is not clear to me why approximating strategies are needed. What  
is the problem? Is Ko the problem? Is an exact computation too slow?

Can anyone shed some light on this?


The classical theory is only for loopfree games (no ko). Then you get  
independent subgames and can talk about sums. Even so, the sum of  
simple games can quickly become very complex.


A great tool for exploring CGT is Aaron Siegel's CGSuite
http://cgsuite.sourceforge.net/

For example, consider a game where Black can either capture n white  
stones, or White can save them. It can be represented as a  
'switch' { 2n | 0 }. Now let's add up several such games with  
different numbers of stones. CGSuite computes the 'canonical form',  
the simplest single game tree representing such a sum.


> {2|0}
{2|0}

> {2|0} + {4|0}
{6|4||2|0}

> {2|0} + {4|0} + {6|0}
{12|10||8|6|||6|4||2|0}

> {2|0} + {4|0} + {6|0} + {8|0}
{20|18||16|14|||14|12||10|812|10||8|6|||6|4||2|0}

> {2|0} + {4|0} + {6|0} + {8|0} + {10|0}
{{30|28||26|24|||24|22||20|1822|20||18|16|||16|14||12|10}|{20|18|| 
16|14|||14|12||10|812|10||8|6|||6|4||2|0}}


> {2|0} + {4|0} + {6|0} + {8|0} + {10|0} + {12|0}
{{42|40||38|36|||36|34||32|3034|32||30|28|||28|26||24|22}|{32|30|| 
28|26|||26|24||22|2024|22||20|18|||18|16||14|12}||{30|28||26|24||| 
24|22||20|1822|20||18|16|||16|14||12|10}|{20|18||16|14|||14|12||10| 
812|10||8|6|||6|4||2|0}}


All these represent very basic Go positions, but the canonical forms  
blow up quickly as we add more subgames.
Now in many cases in Go, you can play optimally without computing the  
sum explicitly. This is explored in the Berlekamp/Wolfe book.

http://www.akpeters.com/product.asp?ProdCode=0326

I implemented a Go program that can solve such puzzles in my PhD thesis.
http://www.cs.ualberta.ca/~mmueller/cgo/thesis.html

In the best case, you can find one move with an "incentive" that  
dominates all other moves, and you can do that with mostly local  
computations. However, in the worst case, there will be "incomparable"  
moves and you have to compute the messy sum.


Approximate methods can hugely reduce the complexity of all this. For  
example, computie only a single number, the temperature, of each  
subgame. But even that can be hard when the local games themselves are  
complicated. In that case, you want approximate methods such as  
Temperature Discovery Search
M. Müller, M. Enzenberger, and J. Schaeffer. Temperature discovery  
search. In Nineteenth National Conference on Artificial Intelligence  
(AAAI 2004), pages 658-663, San Jose, CA, 2004

http://www.cs.ualberta.ca/~mmueller/publications.html#2004

Now ko is a whole other story :)

Martin

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

[computer-go] re-CGT approximating the sum of subgames

[Martin Mueller]

 I can see in your examples here that the space complexity of the  
sum itself grows like 2^terms if the terms are simple forms but not  
numbers.

(I also took the liberty of adding your examples to my unit tests :)
Does computation time grow much faster than this?


Not sure how bad the worst case is. But it does get worse than this,  
because of incomparable options, which multiply in number if both  
players have lots of incomparable options at their choice, etc. In my  
Go example, at least there was always a unique best move, which keeps  
the complexity down somewhat.


In the game Amazons you get lots more incomparable options, e.g. try  
Amazons(".l...","x...r") in CGSuite, and then  
Amazons("l",".","xxx.r"). Then add one more empty square and  
you can go for a long walk :)
In Go, we are often lucky since only one, or a small number, of  
incomparable incentives exist. But I am sure you can construct  
examples that are almost as bad as in Amazons.


I've also stumbled on some complicated articles about loopy games  
(ko) so I realize that there is some ground to cover in that  
direction too :)


I'll read you article about temperature discovery search. Thanks for  
pointing me to it.
Are the techniques in that article improvements over the techniques  
in http://www.icsi.berkeley.edu/ftp/global/pub/techreports/1996/tr-96-030.pdf 
 ?


The topics are a bit different. In the 1996 tech report, we compute  
thermographs for small (but potentially already messy) ko fights. The  
game graphs (the moves of the Go game and the results) were input by  
hand, and the program just computed the thermographs.


In the TDS paper, we deal only with the loopfree case (no ko). We are  
doing a forward search from the starting position, whereas all  
previous methods used bottom-up analysis from end positions. We did  
the experiments in Amazons since we already had the bottom-up data to  
compare with. In the second part of this paper, we try the method on  
subgames that are too complicated to build the whole local game tree.  
We do a time-limited forward search only, but can still get pretty  
good approximations to the real temperature. At least it is good  
enough to completely kill full-board alphabeta :)


Extending TDS for Go (with ko fights) has been on our to-do list for a  
long time. We have an incomplete implementation for that case. But  
there are still unresolved research questions, e.g. how to  
approximately model ko threats in a way that makes the search  
computationally feasible yet informative. No progress in recent years,  
since that Monte-Carlo business has sucked up all my spare time :)


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

[computer-go] The Zen program

[Martin Mueller]

Zen has been getting very impressive results on CGOS. Yamato-san,  
could you tell us a little bit about yourself and your program?


Thanks

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

[computer-go] The Zen Program

[Martin Mueller]

Yamato wrote:

Hi Martin & Rémi, thanks for having interest in my program.
Zen runs on Quad-Core AMD Opteron. I suppose it has nearly the same
strength as Crazy Stone. It is running on KGS now and you can see its
games from here.
http://www.gokgs.com/gameArchives.jsp?user=zen19

I am an individual programmer in Japan. Any questions are welcome.

Dear Yamato-san,
Thank you for your friendly offer. I think many people on this list  
will be curious to hear more about what makes Zen such a strong  
program. Is it similar to Mogo or CrazyStone? Do you use any extra Go  
knowledge? Which other improvements have you found?
I am also interested in hearing your future plans. Will this be a  
commercial product? Will you participate in the Olympiad and in the  
next KGS tournament? Will you have a massively parallel version as well?

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

[computer-go] Fuego technical report

[Martin Mueller]

Our technical report describing the Fuego framework is now available on
http://www.cs.ualberta.ca/research/techreports/2009/TR09-08.php

I will probably make at least one more revision, so all feedback and  
suggestions are welcome.


Thank you

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

[computer-go] Re: Fuego technical report

[Martin Mueller]

How do you set the number of threads that you want Fuego to use?


E.g. for 4 threads

uct_param_search number_threads 4

This can go e.g. in a config file, or you can set it in GoGui in the  
Uct Param Search dialog.
You could also play with pondering on, and reuse the subtree from the  
previous search.

Also, if you have memory, you can increase the node limit.

uct_param_player ponder 1

uct_param_player reuse_subtree 1

uct_param_search max_nodes 1000


Does the windows version support multiple threads?


It should.
Please test and report.

Thank you

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

Re: [computer-go] Cross-Question on Pamplona

[Martin Mueller]

Human players use reading (yomi) and feeling (kankaku) to play Go.
In MC programs, I think the reading is equivalent to UCT, and the  
feeling
is equivalent to playouts. The reading is scalable, the feeling is  
not.

If 2 programs have the playout algorithms of same level, The one which
used more CPU power should win. But what happens if their level of the
playout algorithm were different?  Maybe this is the main reason why  
Zen

could beat Fuego. (The game against MoGo was lucky, not good example.)


In my view, Zen and CrazyStone are clearly the strongest 19x19  
programs on equal PC-type hardware. This is what we saw on CGOS a few  
months ago. I also expected MoGo to still be a few hundred Elo ahead  
of Fuego on 19x19, but this is not how the two games in Pamplona  
turned out. I don't know how other top programs such as Many Faces and  
Leela would compare on 19x19 on equal hardware. Any suggestions?


Maybe we can get all these programs running on CGOS at the same time.  
That would be interesting to get a snapshot of the current situation.


Then there was the rumor that Michael Reiss also had a strong new  
program. I would like to see that one, too.


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

[computer-go] Report on Fuego in Pamplona

[Martin Mueller]

Hello all,

I have uploaded a technical report, mainly with commented Fuego games  
from Pamplona. Lukasz, it has the config settings in an appendix.


Fuego at the Computer Olympiad in Pamplona 2009: a Tournament Report
http://www.cs.ualberta.ca/research/techreports/2009/TR09-09.php

As always, all feedback is welcome, and there can be a revised version  
if needed.


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

[computer-go] Re: Report on Fuego in Pamplona

[Martin Mueller]

Thank you for sharing. And I have a question. Did it use Nakade  
Heuristic

and fillboardTries in the play out policy?


No, we could not get those to work with Fuego. I believe that our  
selfatari correction may have a similar effect to the nakade  
heuristic. I don't remember if we did a lot of testing with Fillboard  
but we have no positive results with it. I know it works very well  
with MoGo, but...


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

[computer-go] re-Is anyone attending IJCAI?

[Martin Mueller]

I will be there for the main conference only.

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

[computer-go] MCTS, 19x19, hitting a wall?

[Martin Mueller]

Part of the problem is that we're using global search to play a game  
with lots of local little fights. If we have say five little fights,  
and each takes say 11 ply to play well, it means a >50 ply global  
search just to avoid local blunders.


Currently, we try to sidestep this fundamental problem by replacing  
local search with local knowledge, such as patterns. But that does not  
fully use the power of search.


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

[computer-go] Re: fuego strength

[Martin Mueller]

I agree with keeping the GnuGo anchor.

My understanding is that Don wanted to bundle one or more fast  
programs with the server, so that some opponents would always be  
available. But I think that the rating of bundled programs should not  
be fixed.


Right now we're relying on volunteers to provide these programs, and  
they have to restart them every time they get thrown off he server.  
Bundling them would be more convenient.


E.g. we could have amigo and averagelib for the low end, and Fuego0.4  
with 1000sim for the middle. If GnuGo is too expensive to run on the  
server, it should still connect frequently enough to keep the ratings  
from drifting away.


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

[computer-go] Random weighted patterns

[Martin Mueller]

If you want to take many samples from a fixed, or infrequently  
changing, distribution, you can do it in O(1) time per sample, with  
O(n) initial setup costs. This is quite clever and goes by the name of  
"alias method".

See http://cg.scs.carleton.ca/~luc/rnbookindex.html, page 107-111

For weighted patterns, the row sum method by Rémi is probably hard to  
beat. It was discussed here a while ago.


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

[computer-go] please fix Fuego4C4PlaPo20Mno on CGOS

[Martin Mueller]

As Hiroshi said in an earlier mail - whoever is running this version  
of Fuego - please fix the config file so that it captures dead stones.  
Just add the line:


go_rules cgos

For example, gnugo-3.7.12-mc scores 22 / 34 against Fuego4C4PlaPo20Mno  
- I suspect because of this issue - while it only scored 2 / 68  
against Fuego-713-2c.


It would be good to use a new name after the fix.
Also, please let us know what you are testing here.

Thanks!

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

[computer-go] RAVE problems

[Martin Mueller]

While RAVE is a very strong heuristic, in Fuego it occasionally  
suppresses the only good move. Do others have similar experiences?  
Here are two cases that I just added to our regression tests. Does  
anyone have more?


http://fuego.svn.sourceforge.net/viewvc/fuego/trunk/regression/blunder_rave.tst?revision=941&view=markup
http://fuego.svn.sourceforge.net/viewvc/fuego/trunk/regression/sgf/rave-problems/

Thanks

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

[computer-go] Bulky nakade shapes (was: Mercy rule position)

[Martin Mueller]

Fuego has no trouble with the mercy rule here - I guess our threshold  
is high enough. However, it has no clue about how to play out the  
nakade shape. So it starts out with 57% wins for White, and it needs  
maybe 30K simulations until the search pushes it below 50%. Then the  
score keeps dropping continually. It is actually a nice example of how  
search can fix bad playouts in Fuego.


Fuego has an effective rule for "stretched" nakade shapes, such as 3  
in a row, T or +. It simply moves the single-stone selfataries to the  
adjacent point. However, it cannot handle the bulky shapes such as in  
Brian's example - it just plays the first move randomly, then usually  
a Mogo-style pattern matches, which makes it likely that two eyes will  
be created. How do others handle such cases in the playouts?


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

[computer-go] Bulky nakade shapes

[Martin Mueller]

Following Mogo, Pebbles uses the "3-in-a-row" modification
that automatically plays in the center of 3-point eyeshapes.
Fuego's rules triples the chance of making a correct play when
a 3-point eyespace exists, but does not guarantee that any play
will be made. The rules do guarantee that the best move will be
made *within* a 3-point eyespace. This allows RAVE to
accelerate discovery of life-giving shape. The only downside that
I have noticed is that straight-four eyespaces are more likely
to die in the playouts, because attacker moves are upgraded to center
points, and pattern replies are not guaranteed to be made on the vital
point.


Interesting. I looked at some playouts from your sample position, and  
I also saw similar problems, e.g. when O's eye space becomes

X..
then O will live with high likelihood in Fuego playouts, since O will  
soon capture the X stone by the capturing rule, but X has no rule to  
play in the center and kill.


When Mogo's rule was first implemented, it made a huge increase
in strength. But when Fuego's rules went in, then Mogo's rule started
being less important, and now it has even become a disadvantage.


Markus implemented Mogo's nakade rule after we had ours, and could not  
get it to work. So it remains switched off in Fuego by default.


It is very interesting to me that you use the clump correction rule. I  
could never get that to work in Fuego, either.


My impression is that Fuego's rules covers a lot of situations,
and the upgraded move is almost always an improvement.

Perhaps Mogo's rule would be beneficial if the number of wasted
moves could be cut down. I have not looked into that.

I have implemented a rule that plays on the vital point of nakade
shapes after captures. That rule has never made much effect on
playing strength, but it looks great in particular cases. It should
work out to be a low-cost positive.


Yes, I was thinking of trying that.

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

[computer-go] Fuego game viewer

[Martin Mueller]

I just put up a viewer with some Fuego games including the win against  
the 9 Dan on

http://www.cs.ualberta.ca/~mmueller/fuego/

I will add more games eventually.

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

Re: [computer-go] Conjectures on Fuego

[Martin Mueller]

Yes, Fuego uses just the 3x3 patterns; its strength is surprising. :-)
Someone conjenctured it is because of how well-tuned its constants  
are.

I also think large part of it is that it seems to use perfect nakade
solver in playouts, so it should be very strong at playout tsumego; at
least in my experiments I'm finding that crucial to strength of my
bot...


It is true that Fuego has no larger patterns. However, playouts also  
use a number of other rules, e.g. for low liberty and selfatari.


Regarding parameter tuning, I am not so sure. This may have been true  
in the past. However, there have been many changes to Fuego in recent  
months, but the parameters have not been re-tuned, so there is  
probably room for improvement.


Fuego is unfortunately also far from perfect in nakade playouts. It  
only implements a simple but effective rule of moving single stone  
selfataries to the adjacent point. This "solves" most stretched nakade  
shapes. However, "bulky" shapes are misplayed with high probability  
(and some with 100% probability...)


A related problem is that even basic false eyes do not necessarily  
stay false during playouts, which leads to optimism about dead groups.  
I recently won a 9 stone test game rather easily after killing a  
medium-size group, which Fuego thought was about 40% alive until  
almost the end of the game. So it played as if it had 20 points more  
than it really had.


So there are still many systematic weaknesses in life and death in  
Fuego, even in pretty simple situations. However, the worst weaknesses  
in 19x19 in my opinion are for tactical fights. It is very surprising  
to me that this program, which plays many tactical blunders that no 15  
kyu would make, can sustain a strong 3 kyu rating on KGS.


I should also mention that we have an experimental version (FuegoEx)  
that uses blunder filtering, tactical searches and larger patterns  
from Explorer for "heavy" nodes in the tree. I believe it applies such  
"classical" knowledge in a similar way to Many Faces. This version is  
probably 1-3 kyu stronger, but not very well tested. FuegoEx was used  
for 19x19 at the Olympiad in Pamplona.


Martin (just back from holiday, still catching up on all these posts)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Conjectures on Fuego

[Martin Mueller]

Interesting! I got confused by GoUctUtil::IsMutualAtari, but now I'm  
not

sure if it is even really used, nor exactly what is it supposed to
actually test in that condition. :-)

Then it turns out that I'm already implementing pretty much all the
tests in Pachi as Fuego is, just probably way too mistuned and buggy,
ah well... ;-) The strange thing is, I don't seem to be getting any
noticeable gain from 2-liberty tactics and checking the pattern at two
last moves instead of just the last one; did you get a big gain from
these?
The aim of mutual atari checking is to keep seki from being destroyed,  
by avoiding moves that are both selfatari and atari on the opponent.  
There are some size limits on the blocks involved, for example you  
need to be able to almost-fill a nakade space by selfatari-ing your  
nakade block.


I had programmed this a long time ago, but while it was working  
beautifully on the seki regression test cases, it lead to a small  
overall decrease in playing strength. It has only become profitable  
(and enabled) shortly before the match against Chou 9p. The reason it  
works now in Fuego is that it is used in conjunction with a  
"balancer", which means that Black and White must use this rule  
roughly equally often. I think we measured about 52% win rate in self- 
play from using mutual atari avoidance plus balancer.


The original version of 2nd-last move pattern improved winning  
percentage against GnuGu from 73% to 78% with 3k simulations. That was  
in November 2007.


2-lib tactics was about 2% improvement around the same time but has  
been improved since.


If I ever write a full paper on Fuego, I will test the effect of  
leaving out each of the existing rules individually. Or even better,  
someone else will do that :)


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

[computer-go] still an outstanding command

[Martin Mueller]

This is caused by the fact that both CzechBot and Fuego (probably)  
were

stuck up in reading, probably either getting dead-locked or stuck in
some infinite loop; so in fact the outstanding command was genmove,  
and

neither of these ever chose which move to play. CzechBot wasn't even
printing out any progress lines.

I think the problem here is that when kgsGtp reconnects, it does not
restart the engine; I think doing that would help a lot in these
situations, since a stuck engine would be restarted by the reconnect.
Right now, after reconnecting, kgsGtp was still waiting for the  
original

genmove command from "old" connection to finish.


Yes, FuegoEx had crashed as well in that game, due to a bug I recently  
introduced.


I think it is OK to lose the one game where it crashes, but it should  
be able to restart for new games at least.


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

[computer-go] Software for a supercomputer?

[Martin Mueller]

> I am now asking for help. Do you know which program could be used  
for
> best performance (or most cores)? Is it easy to set up things  
running?

> (I need to decide soon whether I will organize it or not.)
My guess would be - either Mogo, or Fuego with IBM's BlueFuego MPI  
extension. We have some hope that BlueFuego might scale better than  
Mogo, but have not done any comparison of current systems.


Is this 9x9 or 19x19? How many cores? The systems we have mainly  
tested on are 8 or 10 nodes with 8 shared memory cores in each node  
and infiniband interconnect. E.g. the system that won the 9x9 game  
against Zhou 9-Dan was a 10x8 core.


Is it easy to set up? If you have MPI running it should be OK.

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

[computer-go] First ever win of a computer against a pro 9P as black (game of Go, 9x9).

[Martin Mueller]

Congratulations Olivier and the MoGo team! Good job!
Now let us know the secrets of MoGoTW :)

Did you get pro commentary on the game?

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

[computer-go] Re: More than one Surrounding Block

[Martin Mueller]

I have a question for the group: How is a miai connection strategy  
created for a color enclosed region when their are multiple  
enclosing blocks involved with one or more interior defender  
blocks? Martin Muller's paper "Recognizing Secure Territories in  
Computer Go By Using Static Rules and Search" doesn't go in  
sufficient detail for my understanding. At first it seems obvious,  
especially given the example; however, given a different example  
where there are more than one possible miai strategy, does it  
matter which one is used before generating another miai strategy  
for protecting interior defender blocks? I hope the answer is no.  
But if so, is there an optimal way to generate the miai connection  
strategy? I'd appreciate any references to other papers on the  
subject.


Hello Phil,
Unfortunately, I do not know of an optimal way - unless you want to  
do a backtracking search. There may be different ways to set up miai  
strategies to the same interior point or block - especially if it is  
a large block. I just use some simple heuristic that orders the  
access points, such that those that can not help to access other  
interior points are used up first. I.e. sort by number of interior  
neighbor points, and use the ones with low count first.


Erik v.d.Werf has a recursive improvement on my original 1-level  
scheme - I believe it was posted here. We are also using that one now.


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

[computer-go] Call for Papers: AAAI-08 Nectar Program

[Martin Mueller]

I forward this call for papers since it may be of interest to some of  
you.


Martin



Call for Papers: AAAI-08 Nectar Program

AAAI-08 will be held in Chicago from July 13-17, 2008. It
will again include the Nectar track (new scientific and
technical advances in research). This track aims to make the
most significant AI results presented at other conferences
in the last two years available to a broad AI audience. One
important goal of the track is to offer researchers the
opportunity to learn about areas with which they may not
already be familiar. Another goal is to encourage the sort
of cross-disciplinary AI work that has historically been
supported by AAAI.

The Nectar track will consist of papers that are based on
important results that have already been published in the
proceedings of at least one major conference in 2006 and
2007, as either a single paper or a series of
papers. Examples of such AI conferences include AAMAS,
AIIDE, ALIFE, ACL, CEC, CogSci, CP, FUZZ-IEEE, GECCO, ICAPS,
ICCBR, ICML, IEEE CEC, IJCNN, ISWC, IUI, KCAP, KR, NIPS,
SAT, UAI and WCCI. Examples of conferences in related fields
with relevance to AI include CIKM, COLT, KDD, PODS,
ICDTSIGIR, SIGGRAPH, SIGMOD, VLDB, and WWW.

Papers that report on the application of AI techniques in
other fields, for example bioinformatics, may also serve as
the basis for Nectar papers. Authors of application papers,
however, are advised that they may find the conference on
Innovative Applications of AI (IAAI) a more appropriate
venue for reaching the AI community since those papers can
be longer and thus provide a clearer application setting in
which to describe the work. Papers that have appeared in
general AI conferences (such as AAAI, ECAI, IJCAI) or
journals (for example, Artificial Intelligence, JAIR) cannot
serve as the basis for Nectar papers since they have already
been presented to the entire AI community.

Submissions and Dates

We solicit short submissions of up to four pages. Each
submission should focus on a major result that has already
been published in one or more venues as described above. A
Nectar paper needs to clarify the relationship of the paper
to any other AAAI-08 submissions by the authors and cannot
overlap with them substantially. The Nectar paper should
cite the previous publication(s) and will typically devote
no more than one or two pages to summarizing the core
results. The remainder of the paper should be devoted to
putting the results, as well as the problem they solve, into
a context that is meaningful to a wide AI audience.

Nectar track papers will be presented as talks or posters at
AAAI-08. The papers will also be published in the conference
proceedings. Submitted papers will be reviewed according to:
(1) significance of the results to the broad goals of AI,
(2) potential for the results to influence research beyond
their original publication venues, and (3) clarity of the
presentation to AI researchers who do not have expertise in
the topic described in the paper.

Although papers will describe previously published results,
the paper itself must be original. Authors of accepted
papers will be required to transfer copyright.

Papers must be received by February 19, 2008. Decisions on
the acceptance of papers will be made by March 20, 2008.

Additional information can be found at
www.aaai.org/Conferences/AAAI/2008/aaai08nectar.php

Regina Barzilay (Massachusetts Institute of Technology), Cochair
Sven Koenig (University of Southern California), Cochair

---

Sven Koenig
University of Southern California (USC)
Computer Science Department
Henry Salvatori Computer Center (SAL) 312
941 W 37th Street
Los Angeles, CA 90089-0781, USA
Email: [EMAIL PROTECTED]
WWW:   idm-lab.org___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Fuego parameter question

[Martin Mueller]

> You use the current developers version svn985. Use the stable version fuego 
> 0.4 instead.
> The performance (winning rate) on KGS of the current svn985 is much worse 
> than the 0.4 version as i noticed.
> 
> GK

Hmm, something sounds very wrong here.

a) the current version is 1062, as you can see on
http://fuego.svn.sourceforge.net/viewvc/fuego/trunk/

b) Not sure why you picked 985 especially, but even 985 should be much stronger 
than 0.4 on both 9x9 and 19x19. Recent builds are doing quite well on CGOS:
http://cgos.boardspace.net/9x9/bayes.html
http://cgos.boardspace.net/19x19/bayes.html

c) We have not been running on KGS recently, except for the tournaments where 
Fuego did well - winning the 19x19 in November and second behind Zen in 
December on 9x9. If someone else is running Fuego on another KGS account, maybe 
it uses a slow machine or is not configured right.

http://www.gokgs.com/gameArchives.jsp?user=fuego
http://www.gokgs.com/gameArchives.jsp?user=fuego&year=2009&month=11

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

[computer-go] Reminder: IEEE Transactions on Computational Intelligence and AI in Games Special Issue on Monte Carlo Techniques and Computer Go

[Martin Mueller]

IEEE Transactions on Computational Intelligence and AI in Games 
Special Issue on Monte Carlo Techniques and Computer Go 
Special-issue editors: Chang-Shing Lee, Martin Müller, Olivier Teytaud 

In the last few years Monte Carlo Tree Search (MCTS) has revolutionised 
Computer Go, with MCTS programs such as MoGo, Crazy Stone, Fuego, Many Faces of 
Go, and Zen achieving a level of play that seemed unthinkable only a decade 
ago. These programs are now competitive at a professional level for 9x9 Go, and 
with an 8 stone handicap for 19x19 Go. 
The purpose of this special issue is to publish high quality papers reporting 
the latest research covering the theory and practice of these and other methods 
applied to Go, and also in applying MCTS to other games. 
MCTS can play very well even with little knowledge about the game as evidenced 
by its success in General Game Playing. However, it does not work well for all 
games, which poses some interesting questions. When and why does it succeed and 
fail? How can it be extended to new applications where it does not work yet? 
How best may it be combined with other approaches such as classical minimax 
search and knowledge-based methods? 

Topics include but are not limited to: 
- Emergent Technologies for Computer Go 
- Variants of Go (phantom Go, Go Siege) 
- Knowledge Representation Models for Computer Go 
- MCTS and reinforcement learning 
- MCTS for Video Games 
- Approximation methods for MCTS 
- MCTS for General Game Playing 
- Hybrid MCTS approaches 
- Evolving MCTS players 

Authors should follow normal T-CIAIG guidelines for their submissions, but 
clearly identify their papers for this special issue during the submission 
process. See http://www.ieee-cis.org/pubs/tciaig/ for author information. 
Extended versions of previously published conference papers are welcome 
providing the journal paper provides a significant extension of the conference 
paper, and is accompanied by a covering letter explaining the additional 
contribution.

Schedule 
- Deadline for submissions: March 15, 2010 
- Notification of Acceptance: June 15, 2010 
- Final copy due: October 20, 2010 
- Publication: December 2010 or March 2011 

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

[computer-go] Re: Pachi/fuego GnuGo hybrid

[Martin Mueller]

> Has anyone tried doing pachi/Fuego + GnuGo hybrid slightly in way Many  
> FAces is done?

We have an experimental version that uses knowledge from my old program 
Explorer in Fuego.
It gives a bonus in terms of a number of won simulations to moves considered 
good by the knowledge.
As shown in one of Guillaume Chaslot's papers, you can run expensive knowledge 
in "heavy" nodes in the tree which already had many simulations, since there 
are not many of those.

We have positive results for three types of knowledge on 19x19. Nothing worked 
on 9x9 so far.

1. tactical search - give bonus to move capturing/saving unsettled block of 
stones
2. patterns - give bonus to moves proposed by Explorer's hand-built library of 
patterns (about 4000, irregular size and shape)
3. move filter - hard-prune a small set of moves that Explorer would also 
hard-prune

With each of those in isolation we have 60-70% wins against plain Fuego in fast 
games. We do not know a good combination of the three, since the current 
implementation does not allow us to run more than one such extension at a time. 
It is not hard to generalize, but we have not done it yet, and it would need 
testing/tweaking of parameters.

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

Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go

[Martin Mueller]

I put two commented games on
http://webdocs.cs.ualberta.ca/~mmueller/fuego/Convolutional-Neural-Network.html 


Enjoy!

Martin

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

Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks

[Martin Mueller]

I think many of the programs have a mechanism for dealing with “slow” 
knowledge. For example in Fuego, you can call a knowledge function for each 
node that reaches some threshold T of playouts. The new technical challenge is 
dealing with the GPU. I know nothing about it myself, but from what I read it 
seems to work best in batch mode - you don’t want to send single positions for 
GPU evaluation back and forth.

My impression is that we will see a combination of both in the future - 
“normal”, fast knowledge which can be called as initialization in every node, 
and can be learned by Remi Coulom’s method (e.g. Crazy Stone, Aya, Erica) or by 
Wistuba’s (e.g. Fuego). And then, on top of that a mechanism to improve the 
bias using the slower deep networks running on the GPU.

It would be wonderful if some of us could work on an open source network 
evaluator to integrate with Fuego (or pachi or oakfoam). I know that Clark and 
Storkey are planning to open source theirs, but not in the very near future. I 
do not know about the plans of the Google DeepMind group, but they do mention 
something about a strong Go program in their paper :)

Martin

> Thanks for sharing. I'm intrigued by your strategy for integrating
> with MCTS. It's clear that latency is a challenge for integration. Do
> you have any statistics on how many searches new nodes had been
> through by the time the predictor comes back with an estimation? Did
> you try any prefetching techniques? Because the CNN will guide much of
> the search at the frontier of the tree, prefetching should be
> tractable.
> 
> Did you do any comparisons between your MCTS with and w/o CNN? That's
> the direction that many of us will be attempting over the next few
> months it seems :)

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

[Computer-go] Fuego 1.1 vs current Fuego

[Martin Mueller]

> I ran Fuego (latest svn version) on our machine (Intel(R) Xeon(R) CPU

Aja,
the 1.1 release of Fuego is from 2011 and much different from current svn 
Fuego. Current version has many different kinds of knowledge added. It is also 
much slower, maybe 5x. If you read my blog it explains this a little more.

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

Re: [Computer-go] Fuego 1.1 vs current Fuego

[Martin Mueller]

> You remind me we should write Fuego's version as "1.1.SVN" rather than "1.1”.

Aja,

"1.1.SVN" does not tell the reader anything useful.

the svn revision number is given by the svn info command. That revision number 
allows you to check out the exactly same program version.

% svn info
…
Revision: 1967
…

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

Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks

[Martin Mueller]

Aja and co-authors,

first of all, congratulations on outstanding results!

I have some questions: 

- Would you be willing to share some of the sgf game records played by your 
network with the community? I tried to replay the game record in your paper, 
but got stuck since it does not show any of the moves that got captured.

- Do you know how large is the effect from using the extra features that are 
not in the paper by Clarke and Storkey, i.e. the last move info and the extra 
tactics? As a related question, would you get an OK result if you just zeroed 
out some inputs in the existing net, or would you need to re-train a new 
network from fewer inputs.

- Is there a way to simplify the final network so that it is faster to compute 
and/or easier to understand? Is there something computed, maybe on an 
intermediate layer, that would be usable as a new feature in itself?

Thanks

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

Re: [Computer-go] Fuego 1.1 vs current Fuego

[Martin Mueller]

Hello Hiroshi,

we want to release a version 2.0. There is still some clean-up work to do for a 
release and progress is slow. But there is progress :)

https://sourceforge.net/p/fuego/tickets/ 


Martin


> I also wonder Fuego could release latest version with 1.2, and use
> odd number 1.3.x for development.

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

[Computer-go] Last move info as features

[Martin Mueller]

> From: Stefan Kaitschick  >
...
> Last move info is a strange beast, isn't it? I mean, except for ko
> captures, it doesn't really add information to the position. The correct
> prediction rate is such an obvious metric, but maybe prediction shouldn't
> be improved at any price. To a certain degree, last move info is a kind of
> self-delusion. A predictor that does well without it should be a lot more
> robust, even if the percentages are poorer.

My view is that what we really want to compare is temperature in terms of 
combinatorial game theory, in other words the urgency of playing locally. In 
Go, often the most urgent play remains within the same region for a while. Then 
things cool down, and the most urgent play moves elsewhere. So statistically, 
most of the urgent moves on the board are local replies.

Lacking a direct measure of temperature/urgency, we use “reply locally when 
urgent-looking features exist” as our best cheap approximation.

I have often wondered if a predictor could be trained to just answer this 
question “reply locally or not?” One problem of course is that sometimes the 
answer depends on the whole rest of the board. But often it does not.

As a concrete experiment, we could define “answer locally” e.g. as “within cfg 
distance 4”, and then play the guessing game - how often do professionals and 
programs/predictors agree about answering locally? My guess would be quite 
often, maybe over 80%. The question is whether it would do any good.

If you look at playout policies, they also struggle with the same issue of 
balancing local and nonlocal play in a meaningful way.

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

[Computer-go] UEC cup about to start

[Martin Mueller]

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

Re: [Computer-go] CGT endgame solver

[Martin Mueller]

Hello Josef et al,

unfortunately, not too much has happened since Explorer in terms of applying 
CGT to computer Go. For real play, there are large obstacles in terms of board 
partitioning, selecting strong local moves, and local evaluation (e.g. safety 
of stones, and necessary backfilling moves). I do believe that a combined 
MCTS+CGT approach can be successful, but it is far from trivial. I agree with 
Hideki that endgame may be a weak point of current programs.

The most significant work on CGT+Go that has not been mentioned yet in this 
thread is the work by Elwyn Berlekamp’s PhD students Bill Fraser and Aaron 
Siegel. Both built sophisticated specialized software for interactive analysis 
of human endgames. Their programs allow human experts to partition the board, 
enter all relevant local lines of play by hand, fix any local scoring problems 
(e.g. defensive plays inside territory), then use CGT to compute means and 
temperatures. Both programs can handle complex local ko fights. Especially 
Aaron’s program had several more advanced features as well, such as support for 
merging regions, handling small dependencies between regions, and backing up to 
earlier points in the game.

I always thought that an automated, or at least semi-automated, version of 
their programs would be very useful. I.e. a version that can fill in the 
repetitive final local moves. Explorer can do that, but only for very simple 
endgames - fully surrounded by proven-safe stones, and ko-free on the inside. 
Explorer has never been combined with Bill’s or Aaron’s programs.

By the way I have kept Explorer and its CGT modules working all these years. It 
is now a private extension to Fuego.

In more recent work, we have developed forward search-based approaches for 
computing local temperatures called TDS and TDS+. For simplicity we have tested 
these in the game of Amazons, but I believe that with a little bit of work they 
could be made to work for small Go endgames as well.

M. Müller, M. Enzenberger, and J. Schaeffer. Temperature discovery search 
. In Nineteenth 
National Conference on Artificial Intelligence (AAAI 2004), pages 658-663, San 
Jose, CA, 2004.

Y. Zhang and M. Müller. TDS+: Improving Temperature Discovery Search 
. AAAI 2015, 
pages 1241-1247.


By the way, if anyone here is interested in doing graduate research with me on 
this subject, please let me know.

Martin


On Jul 13, 2015, at 7:20 PM, computer-go-requ...@computer-go.org wrote:
> 
> As far as I know, combinatorial game theory is not used in modern Go
> engines, despite its nice theoretical properties. I have been wondering why
> this is so. Or am I mistaken and some engines do use it? In general, I only
> know about Martin Mueller's Explorer program, which is however slightly
> dated :-). Are there some other solvers?
> 
> I imagine it would be fairly easy to swap from MCTS to a CGT solver once it
> could be applied.. Or is this not interesting for some reason?
> 

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

[Computer-go] How to only play games with correct handicap on KGS?

[Martin Mueller]

I have a new version of Fuego playing on KGS as ranked robot fuego19. I would 
like people to play with correct handicap to get a more reliable rating. Is 
there a way to do this with kgsgtp?

Thanks

Martin

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

[Computer-go] Recognizing Seki

[Martin Mueller]

We wrote a paper 10 years ago about how to recognize seki with “traditional” 
search techniques (not MCTS)

X. Niu, A. Kishimoto, and M. Müller. Recognizing seki in computer Go 
. In J. van den Herik, 
S.-C. Hsu, T.-s. Hsu, and H. Donkers, editors, Advances in Computer Games. 11th 
International Conference, volume 4250 of Lecture Notes in Computer Science, 
pages 88 - 103. Springer, 2006.


http://webdocs.cs.ualberta.ca/~mmueller/publications.html#2006 


Martin

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

Re: [Computer-go] Game 4: a rare insight

[Martin Mueller]

On Mar 13, 2016, at 6:00 AM, computer-go-requ...@computer-go.org wrote:
> 
>> So, what would be Lee's best effort to exploit this? Complicating
>> and playing hopefully-unexpected-tesuji moves?

Judging from this game, setting up multiple interrelated tactical fights, such 
that no subset of them works, but all together they work to capture or kill 
something.

For tactical fights, I would expect the value network to be relatively weaker 
than for quiet territorial positions.
So it comes down to solving the problem by search.

Aja and me wrote a paper a few years back that showed that even on a 9x9 board, 
having two safe but not entirely safe-in-playouts groups on the board confuses 
most Go programs and can push the “bad news” over the search horizon. Now 
imagine having 3, 4, 5 or more simultaneous tactics. The combinatorics of 
searching through all of those by brute force are enormous. But humans know 
exactly what they are looking for.
Martin

Reference:
http://webdocs.cs.ualberta.ca/~mmueller/publications.html#2013
S.-C. Huang and M. Müller. Investigating the Limits of Monte Carlo Tree Search 
Methods in Computer Go 
. 
Computers and Games 2013, p. 39-48. 
Erratum 

 for this paper - in test case 2 Black wins.


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

Re: [Computer-go] PUCT formula

[Martin Mueller]

I talked to Chenjun just now so this is what we both remember.
The PUCB formula as published in Chris Rosin’s paper actually has an additive 
knowledge term, and it looks nothing like the two different PUCT variants tried 
in AlphaGo and our paper.

Chenjun tried an additive term as in Chris’ paper first, and it did not work 
well for him. Then he tried the “UCT-like” PUCT as in our paper, with the decay 
term under the square root. This worked well for him. He never tried the 
AlphaGo formula with the faster decay.

Beyond the published papers, my memory is that many people tried many different 
combinations of knowledge terms and of decay formulas over time. I have never 
read any systematic comparison, or any principled argument for which type of 
decay is “best” for which type of knowledge, and why. It must depend on the 
quality of knowledge, amongst many other things.

There are also earlier MoGo papers that combined many different evaluation 
terms into one formula and tested them empirically.

Martin

> However, the formula in the AGZ paper doesn't look like any "UCT variant". 
> Formula from paper: Cpuct * P(s,a) * sqrt(Sum(N(s,b))) / (1 + N(s,a)) Note 
> that there is no logarithmic term, and the division by N+1 falls outside the 
> sqrt. For comparison, a normal UCT term looks like sqrt(ln(sum(N(s,b))) / (1 
> + N))
> 
> Since I asked my question, I found that other people have also noticed a 
> discrepancy. I saw a post on a DeepChem board about this subject. I also 
> found a paper 
> (https://webdocs.cs.ualberta.ca/~mmueller/ps/2016/2016-Integrating-Factorization-Ranked.pdf)
>  by our old friends Chenjun Xiao and Martin Muller:
> 
> "We apply a variant of PUCT [11] formula which is used in AlphaGo [12] to 
> integrate FBT knowledge in MCTS. " But then the formula that they give 
> differs: argmax((Q(s,a) + Cpuct * P(s,a) * sqrt( lg(N(s)) / (1 + N(s,a)))
> 
> I am guessing that Chenjun and Martin decided (or knew) that the AGZ paper 
> was incorrect and modified the equation accordingly.
> 
> Anyone remember anything about this?
> 
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Hosting mid-level bots on CGOS

[Martin Mueller]

> We're thinking about putting Pachi, Fuego, and the like on CGOS. I have a
> few questions:
> - Are the authors okay with us using our own compute resources to put their
> bots up on CGOS?
> - Do people have recommended hardware / configuration settings to run these
> bots?

Hello Brian,
I can speak for Fuego.
You are welcome to put Fuego back on CGOS.
I recommend that you use the current svn version, not the 1.1 release.
You can think of the current svn version as Fuego 2.0, even though I never made 
an official release with that number.
Fuego profits from more CPU cores and memory, but not from GPU.
For configuration, you can start with sample scripts in
fuego/tools/cgos
and pick/modify from there. I haven’t run them in years so they most likely 
need tweaking.

Martin



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

[Computer-go] Postdoctoral Fellowship, University of Alberta, including Computer Go

[Martin Mueller]

Postdoctoral Fellowship at the University of Alberta in Artificial Intelligence 

Applicants are sought for a postdoctoral position in the Department of 
Computing Science at the University of Alberta. The Department is ranked top 3 
in the world in AI/ML according to csrankings.org.

The successful applicant will work in the research group of Prof. Martin 
Müller. This group studies exploration and learning in the context of heuristic 
search, with applications including two player games and domain-independent 
planning.

Applicants are expected to contribute to one or more of the following projects:

- Heuristic search and learning with imperfect domain models
- Integrating exact solution methods with Alpha Zero type architectures in two 
player games
- Evaluation of deep RL learning against exact solutions in two player games
- Utilizing state similarity in Monte Carlo Tree Search
- Efficient algorithms in combinatorial game theory
- Go Endgame Solver

For further information about these projects see
https://webdocs.cs.ualberta.ca/~mmueller/research/projects.html

Qualifications for the ideal applicant include:
- A recently completed PhD (must be within the last 5 years) in Computing 
Science or similar area, specializing in a field related to one or more of the 
research topics above.
- A demonstrated strong ability in software development and implementation. For 
example, substantial contributions to open source projects.
- Strong mathematical and formal foundations
- A good command of written and oral English
- A research record of publication in top AI venues
- A record of leadership and teamwork in research
- Enthusiasm for expanding skill sets and knowledge

The contract is for one year initially, with the possibility of renewal. 
Depending on interest and ability, there is an option to contribute to teaching 
on the undergraduate and/or graduate level.

Submission materials:
- A cover letter which specifically addresses the job requirements stated 
above. Non-specific applications will be discarded.
- An academic CV
- The names and email addresses of three references
- Two most representative research papers published in English in international 
venues (as pdf or web links)

Deadline for applications: September 15, 2019
Applications will be considered as they are received.
Target start date: November 1, 2019
Please send inquiries and applications to Prof. Müller, mmuel...@ualberta.ca. 
Your subject line must start with the term "DCAI-postdoc".

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

Re: [Computer-go] Crazy Stone is playing on CGOS 9x9

[Martin Mueller]

http://www.yss-aya.com/cgos/viewer.cgi?9x9/SGF/2020/05/07/997479.sgf

Great games! This is my favorite so far. The way black lives inside the
super-safe white area is incredible...

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