Re: [computer-go] cgos clients
On Wed, Jun 17, 2009 at 08:11, Christian Nentwich wrote: > Lukasz, > > your client doesn't seem to be displaying all the info for some reason: > > " -c specified name of config file - this is MANDATORY > -k sepcifies a file to create which will stop client after current game > -p specifies which player plays first game > -s display a sample configuration file to stdout and exit " > I just didn't paste it. > If you add multiple engines, the priority fields will be added up, > normalized to 1.0 and a player will be chosen probabilistically. Thanks. Somehow I assumed that all the programs are run in parallel. > > Christian > p.s. remember also http://cgos-python.sourceforge.net/, which does not have > this feature (yet!), but has others :) nice. Thanks > > On 17/06/2009 00:29, Łukasz Lew wrote: >> >> Hi, >> >> I have a couple of question about cgos client programs. >> >> Why there are two links to clients 32bit linux? >> >> The first one is on page >> http://cgos.boardspace.net/9x9/ >> http://cgos.boardspace.net/public/cgos3-x86_32.zip >> and is broken, but the page refers to it as version 1.1 compared to >> the one on the main page >> http://cgos.boardspace.net/ >> http://cgos.boardspace.net/software/cgosGtp-linux-x86_32.tar.gz >> which works but the version is 0.98. >> >> Can I add some more engines to config file without restarting cgos client? >> >> What is the -p PLAYER_FIRST option ? >> >> cgosGtp 0.98 alpha - engine client for CGOS Linux-x86_64 by Don Dailey >> Usage: /home/lew/cgos/cgosGtp-linux-x86_64/main.tcl -c CONFIG_FILE >> -k KILL_FILE -p PLAYER_FIRST -s >> >> What is the priority in config file? >> >> Thanks >> Lukasz >> ___ >> 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/ > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] opening book structure
I was puzzeling what is the best way to organise an opening book? i am writing a program to be very strong on 7x7 go program (as prelimary for writing a very strong 9x9 program ) and am wondering what is the best structure for an opening book. Where i am at the moment is: There are about 4 fundamentally different ways to structure it 1 a position -> move collection (if the position is such make that move) 2 a position value collection (this position is good, that position is bad for the colur who is on the move) 3 a professional game collection (let the program just play like the pro's) 4 a game tree (game with lots of variations) all have there advantages and disadvantages. 1 is close to what the program uses but is a long list. (difficult to maintain?) 2 same problem as 1 maybe even more extreme, but easy to use for the program 3 are reasonably easy to find. (for standard sizes Godod ed) but has many hiatus (what if my opponent doesn't play like Go Seigen) 4 is easy to use with go editors (Drago ed) but problems with transpositionings ed. I would like to hear from others what kind of opening book they use and why. and how they maintain it. and if i am missing important things. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] opening book structure
2009/6/17 Willemien : > I was puzzeling what is the best way to organise an opening book? It depends of how you program will play. > i am writing a program to be very strong on 7x7 go program (as > prelimary for writing a very strong 9x9 program ) and am wondering > what is the best structure for an opening book. > > Where i am at the moment is: > > There are about 4 fundamentally different ways to structure it > > 1 a position -> move collection (if the position is such make that move) > 2 a position value collection (this position is good, that position is > bad for the colur who is on the move) > 3 a professional game collection (let the program just play like the pro's) I think a bit difficult to find 7x7 pro games. > 4 a game tree (game with lots of variations) > > all have there advantages and disadvantages. What I did in a chess engine was a hash table with positions with the evaluation number. I think if your engine makes Monte Carlo you can store the positions with the probability of winning (and maybe also the number of games with that position). I think that this is number 2 in your list. With a hash you can reenter the book if the game comes from an unkown position. You can make the book with self evaluation (or self playing) or from professional games. Andrés ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] opening book structure
> > I was puzzeling what is the best way to organise an opening book? > Our solution was the following. We have two possible structures: 1) a big set of SGF games; 2) an opening book in which one line contains p,w,l where * p is a situation * w is the number of wins * l is the number of losses We can convert 1) to 2) easily. The advantages are: 1) is quite comfortable for interactions with humans or will self-play games; 2) is much faster to read and to apply for choosing a move with various formulas (it's quite analog to a MCTS tree). In particular, self-play for small boards is efficient for building good opening books - well, I think it's better if you can have human experts, but if you spend sufficiently many computational power on it you can build a good opening book by self-play (the algorithm is by the way quite related to MCTS). Best regards, hope it helps, Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] opening book structure
Are you asking about in-memory storage, or on disk? On disk, you probably want to make sure that it's as easy as possible to maintain - up to your taste. Some people like a single SGF file with variations. You can do mirrorring and transpositions when you load the book. Christian Willemien wrote: I was puzzeling what is the best way to organise an opening book? i am writing a program to be very strong on 7x7 go program (as prelimary for writing a very strong 9x9 program ) and am wondering what is the best structure for an opening book. Where i am at the moment is: There are about 4 fundamentally different ways to structure it 1 a position -> move collection (if the position is such make that move) 2 a position value collection (this position is good, that position is bad for the colur who is on the move) 3 a professional game collection (let the program just play like the pro's) 4 a game tree (game with lots of variations) all have there advantages and disadvantages. 1 is close to what the program uses but is a long list. (difficult to maintain?) 2 same problem as 1 maybe even more extreme, but easy to use for the program 3 are reasonably easy to find. (for standard sizes Godod ed) but has many hiatus (what if my opponent doesn't play like Go Seigen) 4 is easy to use with go editors (Drago ed) but problems with transpositionings ed. I would like to hear from others what kind of opening book they use and why. and how they maintain it. and if i am missing important things. ___ 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] opening book structure
I'm assuming small boards. For big boards it's not practical to have a database style book of course. You definitely must take into considerations board orientations. I suggest using a database where the position is hashed. You can do your own or you can use a lite sql database such as sqlite which is easy to work with. Use a good 64 bit hash of the positions as the key, and determine it some canonical way. If you use a sql database of some sort, you can be pretty flexible and I suggest that you put in flags to identify the source of the moves.For instance you could place moves in the database based on human games, strong computer games, self generated games, hand edited books moves and probably others I didn't think about.If you can specify how the move got into the book you have a great deal of choice about which class of move you use under which conditions.The flags should not be mutually exclusive. Another thing you may want is a quality indicator so that you can specify some moves as tournament quality versus other moves that just provide variety. Even if the book is compiled into your program without using a database, I suggest that it is based on an external sql databse that you can use for editing and developlment.That's probably how I would do it so that the book did not have to be dragged around with the program. Unless of course the book was really large. - Don On Wed, Jun 17, 2009 at 7:44 AM, Willemien wrote: > I was puzzeling what is the best way to organise an opening book? > > i am writing a program to be very strong on 7x7 go program (as > prelimary for writing a very strong 9x9 program ) and am wondering > what is the best structure for an opening book. > > Where i am at the moment is: > > There are about 4 fundamentally different ways to structure it > > 1 a position -> move collection (if the position is such make that move) > 2 a position value collection (this position is good, that position is > bad for the colur who is on the move) > 3 a professional game collection (let the program just play like the > pro's) > 4 a game tree (game with lots of variations) > > > all have there advantages and disadvantages. > > 1 is close to what the program uses but is a long list. (difficult to > maintain?) > 2 same problem as 1 maybe even more extreme, but easy to use for the > program > > 3 are reasonably easy to find. (for standard sizes Godod ed) but has > many hiatus (what if > my opponent doesn't play like Go Seigen) > 4 is easy to use with go editors (Drago ed) but problems with > transpositionings ed. > > I would like to hear from others what kind of opening book they use > and why. and how they maintain it. > and if i am missing important things. > ___ > 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] opening book structure
(I just forgot to mention that we take care of rotations / symetries) I was puzzeling what is the best way to organise an opening book? >> > > Our solution was the following. We have two possible structures: > 1) a big set of SGF games; > 2) an opening book in which one line contains p,w,l where > * p is a situation > * w is the number of wins > * l is the number of losses > > We can convert 1) to 2) easily. > > The advantages are: > 1) is quite comfortable for interactions with humans or will self-play > games; > 2) is much faster to read and to apply for choosing a move with various > formulas (it's quite analog to a MCTS tree). > > In particular, self-play for small boards is efficient for building good > opening books - well, I think it's better if you can have human experts, but > if you spend sufficiently many computational power on it you can build a > good opening book by self-play (the algorithm is by the way quite related to > MCTS). > > Best regards, hope it helps, > Olivier > > > -- = Olivier Teytaud (TAO-inria) olivier.teyt...@inria.fr Tel (33)169154231 / Fax (33)169156586 Equipe TAO (Inria-Futurs), LRI, UMR 8623(CNRS - Universite Paris-Sud), bat 490 Universite Paris-Sud 91405 Orsay Cedex France (one of the 56.5 % of french who did not vote for Sarkozy in 2007) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] opening book structure
> 1 a position -> move collection (if the position is such make that move) > 2 a position value collection (this position is good, that position is > bad for the colur who is on the move) > 3 a professional game collection (let the program just play like the > pro's) > 4 a game tree (game with lots of variations) > hi Willemien, I think there is another important issue in building a opening book, global or local. and if it is local, with fixed shape or irregular shapes? it seems that you want to build a global one, do you? In the 2008 tournament in Beijing, many people had interests in the openning book of Yogo. its openning book is one with local irregular shapes. this book is written by its author a professional Go player. firstly, he build many irregular shapes according to his professional knowledge, and add one or more trees to each shape. these trees may start from no stone, or some certain states of the shape, so there may be many trees at the same time in the openning book.of course, there might be some collisions for different trees might give different choices. when it comes to collisions, we choose one according to the priority, or randomly. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] opening book structure
Many Faces uses position value collection. Positions are hashed and looked up in the position table (with a hash invariant to rotations and reflections). Each node has information about the position (wins, losses, strongest players at this position, etc). It's easy enough to do a 1 ply search to get position -> move values. It's easy to fill the table with professional positions to get a pro game collection. It's easy to map a game tree to the table. So I think this is the most general solution. Earlier versions used a game tree since that is much easier to code. I switched to the position/value collection in version 12. David -Original Message- From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Willemien Sent: Wednesday, June 17, 2009 4:45 AM To: computer-go@computer-go.org Subject: [computer-go] opening book structure I was puzzeling what is the best way to organise an opening book? i am writing a program to be very strong on 7x7 go program (as prelimary for writing a very strong 9x9 program ) and am wondering what is the best structure for an opening book. Where i am at the moment is: There are about 4 fundamentally different ways to structure it 1 a position -> move collection (if the position is such make that move) 2 a position value collection (this position is good, that position is bad for the colur who is on the move) 3 a professional game collection (let the program just play like the pro's) 4 a game tree (game with lots of variations) all have there advantages and disadvantages. 1 is close to what the program uses but is a long list. (difficult to maintain?) 2 same problem as 1 maybe even more extreme, but easy to use for the program 3 are reasonably easy to find. (for standard sizes Godod ed) but has many hiatus (what if my opponent doesn't play like Go Seigen) 4 is easy to use with go editors (Drago ed) but problems with transpositionings ed. I would like to hear from others what kind of opening book they use and why. and how they maintain it. and if i am missing important things. ___ 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] opening book structure
On Wed, Jun 17, 2009 at 9:17 AM, David Fotland wrote: > Many Faces uses position value collection. Positions are hashed and looked > up in the position table (with a hash invariant to rotations and > reflections). Each node has information about the position (wins, losses, > strongest players at this position, etc). It's easy enough to do a 1 ply > search to get position -> move values. It's easy to fill the table with > professional positions to get a pro game collection. It's easy to map a > game tree to the table. So I think this is the most general solution. > > Earlier versions used a game tree since that is much easier to code. I > switched to the position/value collection in version 12. > In my old Goliath program I used positions as hashcodes to lookup a move/value combination because it was much easier to program than trees :) I don't know if it's the best solution, but it worked and it was easy to program. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] opening book structure
On Wed, Jun 17, 2009 at 8:37 PM, Mark Boon wrote: > On Wed, Jun 17, 2009 at 9:17 AM, David Fotland > wrote: > > Many Faces uses position value collection. Positions are hashed and > looked > > up in the position table (with a hash invariant to rotations and > > reflections). Each node has information about the position (wins, > losses, > > strongest players at this position, etc). It's easy enough to do a 1 ply > > search to get position -> move values. It's easy to fill the table with > > professional positions to get a pro game collection. It's easy to map a > > game tree to the table. So I think this is the most general solution. > > > > Earlier versions used a game tree since that is much easier to code. I > > switched to the position/value collection in version 12. > > > > In my old Goliath program I used positions as hashcodes to lookup a > move/value combination because it was much easier to program than > trees :) I think this is the better solution and it's probably easier too. > > > I don't know if it's the best solution, but it worked and it was easy > to program. > > Mark > ___ > 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/
