[Computer-go] 25x25 experiment
On Sun, Apr 26, 2015 at 11:26:42PM +0200, Petr Baudis wrote: On Sun, Apr 26, 2015 at 12:17:01PM +0200, remi.cou...@free.fr wrote: Hi, I thought it might be fun to have a tournament on a very large board. It might also motivate research into more clever adaptive playouts. Maybe a KGS tournament? What do you think? That's a cool idea - even though I wonder if 39x39 is maybe too extreme (I guess the motivation is maximum size KGS allows). I think that actually, GNUGo could become stronger than even the top MCTS programs at some point when expanding the board size, but it's hard for me to estimate exactly when - if at 25x25 or at 49x49... I've let play Pachi (in the same configuration that ranks it as 2d on KGS, but with 15s/move) to play GNUGo for a few games on 25x25 just to see how it would go. I'm attaching three SGFs if anyone would like to take a look, Pachi never had trouble beating GNUGo. Couple of observations: (i) The speed is only about 60% playouts in the same time compared to 19x19. (ii) GNUGo needs to be recompiled to work on larger boards, modify the MAX_BOARD #define in engine/board.h. (Same with Pachi.) (iii) As-is, Pachi might get into stack overflow trouble if ran on larger boards than 25x25. (iv) 25x25 is the last board size where columns can be represented by single English alphabet letters. This is the reason for the GTP limitation, but might trigger other limitations in debug routines etc. (v) The very first game (not included), Pachi lost completely. I discovered that my max playout length was 600 moves; bumping that to 1200 made things boring again. (vi) Some typically fast operations take much longer on large boards, e.g. tree pruning (because much wider tree breadth; on 19x19 it's rarely more than 100ms but it can take seconds on 25x25 for some reason); this would actually make Pachi occassionally lose byoyomi periods by a second or two without a manual time allocation adjustment. And a conjencture: (vii) (Even) games against GNUGo still aren't interesting on 25x25. The same factors that might benefit GNUGo compared to MCTS programs should also benefit DNN players and the difference might be more visible because a DNN should be much stronger than GNUGo. I wonder if the oakfoam or any other effort on building an open source DNN implementation can already play standalone games and how well it works? -- Petr Baudis If you do not work on an important problem, it's unlikely you'll do important work. -- R. Hamming http://www.cs.virginia.edu/~robins/YouAndYourResearch.html z3-0.sgf Description: application/go-sgf z4-0.sgf Description: application/go-sgf z5-0.sgf Description: application/go-sgf ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] How about a 39x39 tournament?
Hi all, I would like to see some bot-vs-bot games on 37x37 or 39x39. Von: Erik van der Werf erikvanderw...@gmail.com Personally I think 39x39 is too big. Also, there is a problem with GTP; the protocol does not support boards over 25x25. Some years ago, Gian-Carlo Pascutto had provided a large-board version of Leela. For that he had introduced a natural extension of the sgf board-coordinates. On 37x37, Leela lost clearly to a human 3-kyu, despite having 8 handicap stones. Ingo. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] How about a 39x39 tournament?
I have just tested: the KGS client only accept board sizes = 25, unfortunately. But 25x25 worked fine with Crazy Stone. Rémi - Mail original - De: Urban Hafner cont...@urbanhafner.com À: computer-go@computer-go.org Envoyé: Lundi 27 Avril 2015 17:51:19 Objet: Re: [Computer-go] How about a 39x39 tournament? That sounds fun. But we should figure out how KGS implements the coordinates for such large boards. On Mon, Apr 27, 2015 at 10:40 AM, Nick Wedd mapr...@gmail.com wrote: I find that I can create KGS tournaments on sizes of board up to 38x38, but not 39x39 and larger. I will gladly do so if there is enough demand. Nick On 27 April 2015 at 08:03, Ingo Althöfer 3-hirn-ver...@gmx.de wrote: Hi all, I would like to see some bot-vs-bot games on 37x37 or 39x39. Von: Erik van der Werf erikvanderw...@gmail.com Personally I think 39x39 is too big. Also, there is a problem with GTP; the protocol does not support boards over 25x25. Some years ago, Gian-Carlo Pascutto had provided a large-board version of Leela. For that he had introduced a natural extension of the sgf board-coordinates. On 37x37, Leela lost clearly to a human 3-kyu, despite having 8 handicap stones. Ingo. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Nick Wedd mapr...@gmail.com ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Blog: http://bettong.net/ Twitter: https://twitter.com/ujh Homepage: http://www.urbanhafner.com/ ___ 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] 25x25 experiment
oakfoam has BOARDSIZE_MAX set to 25, but it seems it is only used to say unsupported board size at the moment :) I think the reason was gtp, but it was set long before I joined the project I dont see a reason, why there should be any problems using it with DNN on 19x19 trained network. If a 25x25 will be sheduled, I will take part :) Detlef Am 27.04.2015 um 12:00 schrieb Petr Baudis: On Sun, Apr 26, 2015 at 11:26:42PM +0200, Petr Baudis wrote: On Sun, Apr 26, 2015 at 12:17:01PM +0200, remi.cou...@free.fr wrote: Hi, I thought it might be fun to have a tournament on a very large board. It might also motivate research into more clever adaptive playouts. Maybe a KGS tournament? What do you think? That's a cool idea - even though I wonder if 39x39 is maybe too extreme (I guess the motivation is maximum size KGS allows). I think that actually, GNUGo could become stronger than even the top MCTS programs at some point when expanding the board size, but it's hard for me to estimate exactly when - if at 25x25 or at 49x49... I've let play Pachi (in the same configuration that ranks it as 2d on KGS, but with 15s/move) to play GNUGo for a few games on 25x25 just to see how it would go. I'm attaching three SGFs if anyone would like to take a look, Pachi never had trouble beating GNUGo. Couple of observations: (i) The speed is only about 60% playouts in the same time compared to 19x19. (ii) GNUGo needs to be recompiled to work on larger boards, modify the MAX_BOARD #define in engine/board.h. (Same with Pachi.) (iii) As-is, Pachi might get into stack overflow trouble if ran on larger boards than 25x25. (iv) 25x25 is the last board size where columns can be represented by single English alphabet letters. This is the reason for the GTP limitation, but might trigger other limitations in debug routines etc. (v) The very first game (not included), Pachi lost completely. I discovered that my max playout length was 600 moves; bumping that to 1200 made things boring again. (vi) Some typically fast operations take much longer on large boards, e.g. tree pruning (because much wider tree breadth; on 19x19 it's rarely more than 100ms but it can take seconds on 25x25 for some reason); this would actually make Pachi occassionally lose byoyomi periods by a second or two without a manual time allocation adjustment. And a conjencture: (vii) (Even) games against GNUGo still aren't interesting on 25x25. The same factors that might benefit GNUGo compared to MCTS programs should also benefit DNN players and the difference might be more visible because a DNN should be much stronger than GNUGo. I wonder if the oakfoam or any other effort on building an open source DNN implementation can already play standalone games and how well it works? ___ 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] May KGS bot tournament, 19x19
Thank you, Peter, for pointing out the error. Gmail automatically detects URLs in emails, and makes them into links. However, it seems it sometimes does it slightly wrong. Here is the corrected message: The May KGS bot tournament will be on Sunday May 3rd, starting at 16:00 UTC and ending by 23:00 UTC. It will use 19x19 boards, with time limits of 14 minutes each plus fast Canadian overtime, and komi of 7.5. There are details at http://www.gokgs.com/tournInfo.jsp?id=956 http://www.gokgs.com/tournInfo.jsp?id=942 Please register by emailing me, with the words KGS Tournament Registration in the email title, at mapr...@gmail.com . On 24 April 2015 at 17:55, Nick Wedd mapr...@gmail.com wrote: The May KGS bot tournament will be on Sunday May 3rd, starting at 16:00 UTC and ending by 23:00 UTC. It will use 19x19 boards, with time limits of 14 minutes each plus fast Canadian overtime, and komi of 7.5. There are details at http://www.gokgs.com/tournInfo.jsp?id=95 http://www.gokgs.com/tournInfo.jsp?id=9426 Please register by emailing me, with the words KGS Tournament Registration in the email title, at mapr...@gmail.com . Nick -- Nick Wedd mapr...@gmail.com -- Nick Wedd mapr...@gmail.com ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] How about a 39x39 tournament?
I find that I can create KGS tournaments on sizes of board up to 38x38, but not 39x39 and larger. I will gladly do so if there is enough demand. Nick On 27 April 2015 at 08:03, Ingo Althöfer 3-hirn-ver...@gmx.de wrote: Hi all, I would like to see some bot-vs-bot games on 37x37 or 39x39. Von: Erik van der Werf erikvanderw...@gmail.com Personally I think 39x39 is too big. Also, there is a problem with GTP; the protocol does not support boards over 25x25. Some years ago, Gian-Carlo Pascutto had provided a large-board version of Leela. For that he had introduced a natural extension of the sgf board-coordinates. On 37x37, Leela lost clearly to a human 3-kyu, despite having 8 handicap stones. Ingo. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Nick Wedd mapr...@gmail.com ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] How about a 39x39 tournament?
That sounds fun. But we should figure out how KGS implements the coordinates for such large boards. On Mon, Apr 27, 2015 at 10:40 AM, Nick Wedd mapr...@gmail.com wrote: I find that I can create KGS tournaments on sizes of board up to 38x38, but not 39x39 and larger. I will gladly do so if there is enough demand. Nick On 27 April 2015 at 08:03, Ingo Althöfer 3-hirn-ver...@gmx.de wrote: Hi all, I would like to see some bot-vs-bot games on 37x37 or 39x39. Von: Erik van der Werf erikvanderw...@gmail.com Personally I think 39x39 is too big. Also, there is a problem with GTP; the protocol does not support boards over 25x25. Some years ago, Gian-Carlo Pascutto had provided a large-board version of Leela. For that he had introduced a natural extension of the sgf board-coordinates. On 37x37, Leela lost clearly to a human 3-kyu, despite having 8 handicap stones. Ingo. ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Nick Wedd mapr...@gmail.com ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Blog: http://bettong.net/ Twitter: https://twitter.com/ujh Homepage: http://www.urbanhafner.com/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] May KGS bot tournament, 19x19
This is weird. My corrected message now highlights all three digits of 956, but still links to tournament 942. The correct link is, I hope, a href=http://www.gokgs.com/tournInfo.jsp?id=956; http://www.gokgs.com/tournInfo.jsp?id=956/a On 27 April 2015 at 09:48, Nick Wedd mapr...@gmail.com wrote: Thank you, Peter, for pointing out the error. Gmail automatically detects URLs in emails, and makes them into links. However, it seems it sometimes does it slightly wrong. Here is the corrected message: The May KGS bot tournament will be on Sunday May 3rd, starting at 16:00 UTC and ending by 23:00 UTC. It will use 19x19 boards, with time limits of 14 minutes each plus fast Canadian overtime, and komi of 7.5. There are details at http://www.gokgs.com/tournInfo.jsp?id=956 http://www.gokgs.com/tournInfo.jsp?id=942 Please register by emailing me, with the words KGS Tournament Registration in the email title, at mapr...@gmail.com . On 24 April 2015 at 17:55, Nick Wedd mapr...@gmail.com wrote: The May KGS bot tournament will be on Sunday May 3rd, starting at 16:00 UTC and ending by 23:00 UTC. It will use 19x19 boards, with time limits of 14 minutes each plus fast Canadian overtime, and komi of 7.5. There are details at http://www.gokgs.com/tournInfo.jsp?id=95 http://www.gokgs.com/tournInfo.jsp?id=9426 Please register by emailing me, with the words KGS Tournament Registration in the email title, at mapr...@gmail.com . Nick -- Nick Wedd mapr...@gmail.com -- Nick Wedd mapr...@gmail.com -- Nick Wedd mapr...@gmail.com ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 25x25 experiment
Sorry, it is not,
but I offer my trained DCNN http://physik.de/net.tgz
it has about 44% prediction rate and uses only the position
it a a caffe file which is quite easy to use:
void Engine::getCNN(Go::Board *board,Go::Color col, float result[])
{
int size=board-getSize();
float *data;
data= new float[2*size*size];
//fprintf(stderr,2\n);
if (col==Go::BLACK) {
for (int j=0;jsize;j++)
for (int k=0;ksize;k++)
{//fprintf(stderr,%d %d %d\n,i,j,k);
if (board-getColor(Go::Position::xy2pos(j,k,size))==Go::BLACK)
{
data[j*size+k]=1.0;
data[size*size+size*j+k]=0.0;
}
else if
(board-getColor(Go::Position::xy2pos(j,k,size))==Go::WHITE)
{
data[j*size+k]=0.0;
data[size*size+size*j+k]=1.0;
}
else
{
data[j*size+k]=0.0;
data[size*size+size*j+k]=0.0;
}
}
}
if (col==Go::WHITE) {
for (int j=0;jsize;j++)
for (int k=0;ksize;k++)
{//fprintf(stderr,%d %d %d\n,i,j,k);
if (board-getColor(Go::Position::xy2pos(j,k,size))==Go::BLACK)
{
data[j*size+k]=0.0;
data[size*size+size*j+k]=1.0;
}
else if
(board-getColor(Go::Position::xy2pos(j,k,size))==Go::WHITE)
{
data[j*size+k]=1.0;
data[size*size+size*j+k]=0.0;
}
else
{
data[j*size+k]=0.0;
data[size*size+size*j+k]=0.0;
}
}
}
Blobfloat *b=new Blobfloat(1,2,size,size);
b-set_cpu_data(data);
vectorBlobfloat* bottom;
bottom.push_back(b);
const vectorBlobfloat* rr = caffe_test_net-Forward(bottom);
//for (int j=0;j19;j++)
//{
//for (int k=0;k19;k++)
//{
//fprintf(stderr,%5.3f ,rr[0]-cpu_data()[j*19+k]);
//}
//fprintf(stderr,\n);
//}
for (int i=0;isize*size;i++) {
result[i]=rr[0]-cpu_data()[i];
if (result[i]0.1) result[i]=0.1;
}
delete[] data;
delete b;
}
Am 27.04.2015 um 13:44 schrieb Petr Baudis:
On Mon, Apr 27, 2015 at 12:35:05PM +0200, Detlef Schmicker wrote:
I dont see a reason, why there should be any problems using it with
DNN on 19x19 trained network. If a 25x25 will be sheduled, I will
take part :)
I'm sorry for being unclear! I actually meant DCNN as a standalone
player, not part of MCTS. Is it possible to run oakfoam's DCNN
implementation like that? (Have you measured its stength?)
Thanks,
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] How about a 39x39 tournament?
On 27-04-15 09:03, Ingo Althöfer wrote: Some years ago, Gian-Carlo Pascutto had provided a large-board version of Leela. For that he had introduced a natural extension of the sgf board-coordinates. I just followed the official specification, which allows up to 52x52: http://www.red-bean.com/sgf/go.html http://www.red-bean.com/sgf/index.html -- GCP ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] 25x25 experiment
On Mon, Apr 27, 2015 at 12:35:05PM +0200, Detlef Schmicker wrote: I dont see a reason, why there should be any problems using it with DNN on 19x19 trained network. If a 25x25 will be sheduled, I will take part :) I'm sorry for being unclear! I actually meant DCNN as a standalone player, not part of MCTS. Is it possible to run oakfoam's DCNN implementation like that? (Have you measured its stength?) Thanks, Petr Baudis ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
[Computer-go] Three Lectureships
This may be of interest to readers of this list. We are looking for people of outstanding ability who are passionate about research and education. The lectureships are in: · Computer Science and Artificial Intelligence · Computer Games and Artificial Intelligence · Computational Finance These are tenure track, and equivalent to Assistant Professor grade. Of special interest to this list is that we’re looking to expand our teaching of computer games at Essex, with an exciting new MSc in the area. Closing date for applications: May 28, 2015 Preferred starting date: September 1, 2015 Starting Salary £38,511 - £45,954 (GBP) per annum More details: http://tinyurl.com/cseejobs Best wishes, Simon Lucas Professor Simon Lucas Head of School Computer Science and Electronic Engineering University of Essex, UK https://www.essex.ac.uk/csee/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Utilizing multiple parametersets/bias systems/bots
Hi, Marc, You may want to take a look at my papers, they are kind of related to these ideas (although I didn't yet change the team on the fly, as you are suggesting): * http://teamcore.usc.edu/people/sorianom/aaai14.pdf * http://teamcore.usc.edu/papers/2013/ijcai13.pdf * http://teamcore.usc.edu/people/sorianom/AAMAS2011.pdf Concerning changing the settings dynamically, my most recent work may help (when using voting): * http://teamcore.usc.edu/papers/2015/aamas2015.pdf Let me know if you have questions/comments... :) Best, Leandro On Sun, Apr 26, 2015 at 7:59 AM, Marc Landgraf mahrgel...@gmail.com wrote: Heya, I lately tried to think about, whether it would be possible to combine the strengths of different bots, or at least different parameter sets/bias systems for one bots in some way. They may shine at different situations/phases during the game, but how to figure out, which one is currently the better one? What I now came up with, was the following: For simplicity we assume for now, that our different bots are using the same playouts, but different approaches during the tree phase. So maybe they use different ways to bias nodes, different selection formulas etc. Gonna focus on them using different bias systems. Now you split up your playouts in percentiles: 25%: Bot1 selects the white moves, Bot2 the black ones 25%: the other way around 0x%50%: Bot1 selects for both. 50%-x%: Bot2 selects for both. You track the win rates of those first 2 quarters separately and also calculate winrate of Bot1 vs Bot2. Now if the bots are identical obviously both should win 50%. But if the bots are different, you may see different results. E.g. when Bot1 wins 55% of his games, his move selection is probably better then Bot2's move selection. Here you have to be careful about wrong conclusions, because if you would setup a depth-first bot vs a width-first you would certainly also get win rates heavily in favor of the depth-first. But where this could shine is, when using different bias systems. Because it actually tells you, which bias system is doing better in the current board situation. Now you can use that knowledge to calculate x. E.g. if either bot wins 60%+ he gains all 50% of the remaining playouts, and let the balance slide linearly, if the win rate is 40-60% for the bots against each other. (use whatever formula here, open for testing) This should enable you to figure out on the fly, which bias system is doing a better job at the current situation, while doing playouts. You are just tracking some additional stats. Of course, there are pros and cons to this method: + In general, switching selection method in the tree should not cost any time, and tracking those additional stats also costs close to no time. Only additional time used comes from using a second bias function or similar (because now you have to calculate the bias twice, for most nodes) - At the same time, the amount of data is actually increasing, because you have to track the stats for the different bots. This may cause memory issues! (but when using a distributed memory solution anyway, it does not create additional data, if each memory/thread unit is assigned to one of those percentiles of playouts) +- In general the costs increase depends on how different the 2 Bots are. If they are the same, there would be basically no cost. + Allows you to figure out, which bot/bias/selection is doing better right now - but may lead to false conclusions, like above mentioned depth vs width example +- As long as both bots are of similar strength, you should not lose from using this kind of system. Worst case is, that you play the wrong bots move, if you had above mentioned false conclusions. But when they are close in strength, that is not worse than using just one bot all the time. Of course, if one bot is dominating the other one in all situations, you are losing quality, when figuring out again and again, that this is the case. (because in 50% of the playouts, half of the moves were selected by the worse bot) So some quick ideas how it could be modified further: - all percentages are obviously placeholders and could be adjusted (even dynamically) - assuming you have a low cost and a very high time cost bias function, you can actually check, if it is worth using the high cost bias function, or if the board situation is simple enough to churn out more playouts using the cheaper function. - identifying certain game situations: you may know, that one bias is doing much better in corner fights or liberty races, so if that one is dominating, you are probably in such a situation and can now adjust further (e.g. modify playouts, add additional routines, whatever) - using more then 2 routines, possibly in conjunction with the idea above to identify situations. Of course, one could now also think how to expand this idea, with using different playouts, but I'm not sure how to judge,
