RE: [computer-go] Basic question concerning the edges of the board
Ah alright. I will try to see if I can implement the idea from the comments thus far. Thanks everyone. I probably have a followup question. --- On Mon, 7/13/09, David Fotland wrote: > From: David Fotland > Subject: RE: [computer-go] Basic question concerning the edges of the board > To: "'computer-go'" > Date: Monday, July 13, 2009, 8:04 PM > There was computer go before this > list :) I heard this idea from Mark > sometime around 1988. > > David > > > -Original Message- > > From: computer-go-boun...@computer-go.org > [mailto:computer-go- > > boun...@computer-go.org] > On Behalf Of Carter Cheng > > Sent: Monday, July 13, 2009 10:27 AM > > To: computer-go > > Subject: Re: [computer-go] Basic question concerning > the edges of the > board > > > > > > Thanks all for the replies. I am not sure I quite get > the 20x21+2 idea but > > I will take a look back in the archives. Does anyone > remember roughly when > > it was posted to the list? > > > > Thanks again, > > > > Carter. > > > > --- On Mon, 7/13/09, Peter Drake > wrote: > > > > > From: Peter Drake > > > Subject: Re: [computer-go] Basic question > concerning the edges of the > > board > > > To: "computer-go" > > > Date: Monday, July 13, 2009, 9:08 AM > > > As in LibEGO, if you define the > > > off-board points to be both black AND white, > finding > > > captures requires fewer branches. > > > Peter Drakehttp://www.lclark.edu/~drake/ > > > > > > > > > On Jul 13, 2009, at 8:48 AM, David Fotland > > > wrote: > > > I use one dimensional arrays for speed (to > > > avoid a multiply by 21). > > > > > > Old Many Faces code uses arrays of 363 (361 > points, pass, > > > and null-point). > > > The smallest possible arrays were required to run > under 500 > > > KB total memory. > > > I avoided edge checks by having a set of small > offset > > > arrays (with 2, 3, or > > > 4 offsets), chosen by the board. > > > > > > My MCTS code uses single dimension arrays with > size > > > suggested by Mark Boon, > > > from Goliath, 20 * 21 + 2. This is enough to > have > > > points off the edge on > > > all sides and diagonals. > > > > > > David > > > > > > -Original Message- > > > From: > > > computer-go-boun...@computer-go.org > [mailto:computer-go- > > > boun...@computer-go.org] > > > On Behalf Of Carter Cheng > > > Sent: Monday, July 13, > > > 2009 8:36 AM > > > To: computer-go@computer-go.org > > > Subject: [computer-go] > > > Basic question concerning the edges of the board > > > > > > > > > Hi, > > > > > > I have again been > > > considering trying my hand at implementing a > simple go > > > program. The question > > > I have pertains to checking for the edge of the > > > board > > > in capture situations and so on. > > > For a modern CPU (given what limited > > > information I have on > > > this) the extra branches might result in > pipeline > > > stalls if I am > > > constantly checking if values are in range. Is it > best to > > > extend the size of the > > > board to say 21x21 to somehow avoid these sorts > of > > > checks? Or are the > > > relative cost of these branches negligible in > the > > > scheme > > > of things? > > > > > > Thanks in advance, > > > > > > Carter. > > > > > > > > > > > > ___ > > > 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/ > > > > > > > > > -Inline Attachment Follows- > > > > > > ___ > > > 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 mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Dynamic komi in commercial programs
Darren Cook wrote: > Ingo's suggestion (of two buttons to increment/decrement komi by one > point) was to make it easy for strong humans to test out the idea for us. Don Dailey wrote: > There is no question that if you provide a button to push, all kinds > of positions will appear where this idea works. Providing a button is > not nearly the same as providing an actual working algorithm that you > can prove is superior. Right. Especially it may turn out that dynamic komi works well as a tool in computer-aided analysis. To give an example, the very new version 12.013 of "Many Faces of Go" has a feature: the program does not only compute its best move but also shows percentages for alternative "popular moves" (name coined by David Fotland). Here is a screenshot http://www.althofer.de/image-fotland.jpg or in context http://www.althofer.de/k-best-visualisations.html Of course, this feature not at all improves the playing strength of autonomous Many Faces. But it is a very hepful tool for computer- aided analysis of positions. The experience from almost two decades of chess programs on the pc: when you give users such tools to "play" with you will earlier or later get very helpful feedback. Ingo. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Dynamic komi in commercial programs
On Tue, Jul 14, 2009 at 4:07 AM, "Ingo Althöfer" <3-hirn-ver...@gmx.de>wrote: > Darren Cook wrote: > > Ingo's suggestion (of two buttons to increment/decrement komi by one > > point) was to make it easy for strong humans to test out the idea for us. > > Don Dailey wrote: > > There is no question that if you provide a button to push, all kinds > > of positions will appear where this idea works. Providing a button is > > not nearly the same as providing an actual working algorithm that you > > can prove is superior. > > Right. Especially it may turn out that dynamic komi works well as a > tool in computer-aided analysis. > > > To give an example, the very new version 12.013 of "Many Faces of Go" > has a feature: the program does not only compute its best move but > also shows percentages for alternative "popular moves" (name coined > by David Fotland). > > Here is a screenshot > http://www.althofer.de/image-fotland.jpg > or in context > http://www.althofer.de/k-best-visualisations.html > > Of course, this feature not at all improves the playing strength > of autonomous Many Faces. But it is a very hepful tool for computer- > aided analysis of positions. > > The experience from almost two decades of chess programs on the pc: > when you give users such tools to "play" with you will earlier or > later get very helpful feedback. But this to me is just a random feature - it seems like many other more useful features would be much higher priority than a pseudo komi feature. - Don > > > Ingo. > > -- > Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate > für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > ___ > 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] memory management for search trees(basic question)
This is something I have been curious about since I am somewhat new to writing code in languages which require explicit memory management (as opposed to have some sort of garbage collector do it for you). The question is how do most programs manage memory w.r.t. the search nodes? Is the memory preallocated in advance or is there some strategy to grow the space required as the nodes accumulate during a search? Thanks in advance, Carter. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] memory management for search trees(basic question)
Preallocate in advance. Allocating memory on the fly is expensive. Peter Drake http://www.lclark.edu/~drake/ On Jul 14, 2009, at 8:06 AM, Carter Cheng wrote: This is something I have been curious about since I am somewhat new to writing code in languages which require explicit memory management (as opposed to have some sort of garbage collector do it for you). The question is how do most programs manage memory w.r.t. the search nodes? Is the memory preallocated in advance or is there some strategy to grow the space required as the nodes accumulate during a search? Thanks in advance, Carter. ___ 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] memory management for search trees(basic question)
There has been quite a few descriptions on this forum about how people do this. I am guessing, but I think most of the authors allocate a pool of memory and manage this themselves.Are you writing in C? In C you can declare a fixed size record (called a struct) and just make an array of them.This is what my program does. When I need new nodes I just use the next ones available and a counter keeps track of where I am. It's a little more complicated if you also need to remove nodes. I don't do this. When a new search begins I can just start over again. I think there are a lot of variations of what people do.Perhaps a better way is to use a hash table instead of a tree. It's still a tree of course but structured different. With a hash table a zobrist key is used to index into a hash table. So you can build your tree this way, again using a fixed pool of nodes or whatever hash table method you need to.One advantage of a hash table is that with transpositions you can resuse information that has already been computed - but one disadvantage is that you have to deal with Graph History Interaction (GHI.) I think most program ignore GHI for the most part (in a similar way that computer chess programmers ignore the problem) but I'm not real sure on this one. You can also use malloc and free to allocate space for nodes - but it is well known that this can be challenging for writing bug free programs. I have found that you can almost always avoid it and I personally only use it for top level data structures - for instance I might allocate my initial fixed pool of nodes this way (and so it can be user configurable) but I won't allocate and free individual nodes. Also, if you use malloc and free you will surely see a slowdown. Another option is to use the Hans Boehm garbage collector, a library you simple link to in your C programs.It will do the automated garbage collection for you - but I think you will see a slowdown and I think there is a memory overhead penality for using this as it probably needs working space. - Don On Tue, Jul 14, 2009 at 11:06 AM, Carter Cheng wrote: > > This is something I have been curious about since I am somewhat new to > writing code in languages which require explicit memory management (as > opposed to have some sort of garbage collector do it for you). The question > is how do most programs manage memory w.r.t. the search nodes? Is the memory > preallocated in advance or is there some strategy to grow the space required > as the nodes accumulate during a search? > > Thanks in advance, > > Carter. > > > > ___ > 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] memory management for search trees(basic question)
Thanks for the replies. I will most likely be writing in C++ given the additional abstraction mechanisms and my current lack of understanding of preprocessor #define type tricks. I remember reading about Zobrist's hash functions in some old messages on the list and some papers on the GHI issue but at this point I am still just implementing the basic light playout simulation code so I haven't quite gotten here yet. I wonder concerning GHI for doing searches in go that you could in principle encode extra information into the "position" key which could be use to discriminate board positions which appear to be the same but differ in crucial ways. Thanks everyone for the help. --- On Tue, 7/14/09, Don Dailey wrote: > From: Don Dailey > Subject: Re: [computer-go] memory management for search trees(basic question) > To: "computer-go" > Date: Tuesday, July 14, 2009, 8:32 AM > There has been quite a few descriptions > on this forum about how people do this. > > I am guessing, but I think most of the authors allocate a > pool of memory and manage this themselves. Are you > writing in C? > > > In C you can declare a fixed size record (called a > struct) and just make an array of them. This is what > my program does. When I need new nodes I just use the > next ones available and a counter keeps track of where I > am. > > > It's a little more complicated if you also need to > remove nodes. I don't do this. When a new search > begins I can just start over again. > > I think there are a lot of variations of what people > do. Perhaps a better way is to use a hash table > instead of a tree. It's still a tree of course but > structured different. With a hash table a zobrist key is > used to index into a hash table. So you can build your > tree this way, again using a fixed pool of nodes or > whatever hash table method you need to. One advantage > of a hash table is that with transpositions you can resuse > information that has already been computed - but one > disadvantage is that you have to deal with Graph History > Interaction (GHI.) I think most program ignore GHI > for the most part (in a similar way that computer chess > programmers ignore the problem) but I'm not real sure on > this one. > > > You can also use malloc and free to allocate space for > nodes - but it is well known that this can be challenging > for writing bug free programs. I have found that you can > almost always avoid it and I personally only use it for top > level data structures - for instance I might allocate my > initial fixed pool of nodes this way (and so it can be user > configurable) but I won't allocate and free individual > nodes. > > > Also, if you use malloc and free you will surely see a > slowdown. > > Another option is to use the Hans Boehm garbage collector, > a library you simple link to in your C programs. It > will do the automated garbage collection for you - but I > think you will see a slowdown and I think there is a memory > overhead penality for using this as it probably needs > working space. > > > - Don > > > > On Tue, Jul 14, 2009 at 11:06 AM, > Carter Cheng > wrote: > > > > This is something I have been curious about since I am > somewhat new to writing code in languages which require > explicit memory management (as opposed to have some sort of > garbage collector do it for you). The question is how do > most programs manage memory w.r.t. the search nodes? Is the > memory preallocated in advance or is there some strategy to > grow the space required as the nodes accumulate during a > search? > > > > > Thanks in advance, > > > > Carter. > > > > > > > > ___ > > computer-go mailing list > > computer-go@computer-go.org > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > > > -Inline Attachment Follows- > > ___ > 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] memory management for search trees(basic question)
There are many ways to skin a cat. I allocate them dynamically, but recycle the nodes no longer needed for performance. And I use 'aspect programming' that optionally (after a recompile) checks for dangling pointers. Mark On Jul 14, 2009, at 5:06 AM, Carter Cheng wrote: This is something I have been curious about since I am somewhat new to writing code in languages which require explicit memory management (as opposed to have some sort of garbage collector do it for you). The question is how do most programs manage memory w.r.t. the search nodes? Is the memory preallocated in advance or is there some strategy to grow the space required as the nodes accumulate during a search? Thanks in advance, Carter. ___ 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] memory management for search trees(basic question)
I think most programs completely ignore this issue except for simple ko. I think for all practical purposes you can consider 2 positions identical if they have the same set of legal moves possible, considering only simple ko. Of course this is not entirely correct, but I don't think it will weaken the program in any way that you could easily detect.At any rate, the cure might weaken the program more than the disease. You probably don't want to ignore this in the tree itself though. If a move is illegal due to any kind of ko, don't expand it. So your tree will be proper and correct, but some particular node may have data generated from positions that are technically different due to GHI issues. If anyone handles this any differently, it would be good to say something here ... - Don On Tue, Jul 14, 2009 at 12:10 PM, Carter Cheng wrote: > > Thanks for the replies. I will most likely be writing in C++ given the > additional abstraction mechanisms and my current lack of understanding of > preprocessor #define type tricks. > > I remember reading about Zobrist's hash functions in some old messages on > the list and some papers on the GHI issue but at this point I am still just > implementing the basic light playout simulation code so I haven't quite > gotten here yet. > > I wonder concerning GHI for doing searches in go that you could in > principle encode extra information into the "position" key which could be > use to discriminate board positions which appear to be the same but differ > in crucial ways. > > Thanks everyone for the help. > > > --- On Tue, 7/14/09, Don Dailey wrote: > > > From: Don Dailey > > Subject: Re: [computer-go] memory management for search trees(basic > question) > > To: "computer-go" > > Date: Tuesday, July 14, 2009, 8:32 AM > > There has been quite a few descriptions > > on this forum about how people do this. > > > > I am guessing, but I think most of the authors allocate a > > pool of memory and manage this themselves.Are you > > writing in C? > > > > > > In C you can declare a fixed size record (called a > > struct) and just make an array of them.This is what > > my program does. When I need new nodes I just use the > > next ones available and a counter keeps track of where I > > am. > > > > > > It's a little more complicated if you also need to > > remove nodes. I don't do this. When a new search > > begins I can just start over again. > > > > I think there are a lot of variations of what people > > do.Perhaps a better way is to use a hash table > > instead of a tree. It's still a tree of course but > > structured different. With a hash table a zobrist key is > > used to index into a hash table. So you can build your > > tree this way, again using a fixed pool of nodes or > > whatever hash table method you need to.One advantage > > of a hash table is that with transpositions you can resuse > > information that has already been computed - but one > > disadvantage is that you have to deal with Graph History > > Interaction (GHI.) I think most program ignore GHI > > for the most part (in a similar way that computer chess > > programmers ignore the problem) but I'm not real sure on > > this one. > > > > > > You can also use malloc and free to allocate space for > > nodes - but it is well known that this can be challenging > > for writing bug free programs. I have found that you can > > almost always avoid it and I personally only use it for top > > level data structures - for instance I might allocate my > > initial fixed pool of nodes this way (and so it can be user > > configurable) but I won't allocate and free individual > > nodes. > > > > > > Also, if you use malloc and free you will surely see a > > slowdown. > > > > Another option is to use the Hans Boehm garbage collector, > > a library you simple link to in your C programs.It > > will do the automated garbage collection for you - but I > > think you will see a slowdown and I think there is a memory > > overhead penality for using this as it probably needs > > working space. > > > > > > - Don > > > > > > > > On Tue, Jul 14, 2009 at 11:06 AM, > > Carter Cheng > > wrote: > > > > > > > > This is something I have been curious about since I am > > somewhat new to writing code in languages which require > > explicit memory management (as opposed to have some sort of > > garbage collector do it for you). The question is how do > > most programs manage memory w.r.t. the search nodes? Is the > > memory preallocated in advance or is there some strategy to > > grow the space required as the nodes accumulate during a > > search? > > > > > > > > > > Thanks in advance, > > > > > > > > Carter. > > > > > > > > > > > > > > > > ___ > > > > computer-go mailing list > > > > computer-go@computer-go.org > > > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > > > > > > > > -Inline Attachment Follows- > > > > __
Re: [computer-go] memory management for search trees(basic question)
On Jul 14, 2009, at 9:58 AM, Don Dailey wrote: I think most programs completely ignore this issue except for simple ko.I think for all practical purposes you can consider 2 positions identical if they have the same set of legal moves possible, considering only simple ko. Orego's Zobrist hash includes the stones on the board, the simple ko position, and whose turn it is. You probably don't want to ignore this in the tree itself though. If a move is illegal due to any kind of ko, don't expand it. So your tree will be proper and correct, but some particular node may have data generated from positions that are technically different due to GHI issues. We only check for superko right before actually making a move (i.e., not in the tree or in playouts). Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Dynamic komi in commercial programs
- Original Message - From: "Dave Dyer" To: "computer-go" Sent: Saturday, July 11, 2009 10:54 PM Subject: [computer-go] Re: Dynamic komi in commercial programs If you are in a lost position, "good play" is play that maximizes the probability of a turnaround, which is quite different depending on how far behind you are, and for what reason. If the status of all the major groups is solid, then concentrating on tactics which can gain a few points reliably might be the right thing. On the other hand, if the status of some groups is less than immutable, then focusing on changing their status favorably might be correct. It's hard to see how shifting Komi will influence the style of play in this direction. Dynamic komi in a sense means that the bot is deluding itself on purpose. Obviously this is dangerous medicine, a kind of magic mushroom. So what could be worse than a deluded bot? I say, letting a monkey play could be worse. And monkeys' play is what you get from an mc bot when all possible moves come back with indistinguishably wonderful or terrible win rates. Adding a wishful (or pessimistic) komi will distort reality, but will help create bigger win rate differences between moves. It should be possible to assign costs to both dynamic komi and to insufficiently spreading win rates between moves. My hypothesis is, that with unstable groups on the board, the win-rate spread will tend to be larger then with stable groups. So with proper balancing, the bot should refuse to take dynamic komi when he sees a chance to win outright. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Dynamic komi in commercial programs
Maybe we should go back to the question which dynamic komi is an attempt to solve: how to obtain better discrimination when every move seems to be clustered near "I am so freaking dead" or "I am so far ahead", as the case may be. Terry McIntyre “We hang the petty thieves and appoint the great ones to public office.” -- Aesop From: Stefan Kaitschick To: computer-go Sent: Tuesday, July 14, 2009 3:17:38 PM Subject: Re: [computer-go] Re: Dynamic komi in commercial programs Dynamic komi in a sense means that the bot is deluding itself on purpose. Obviously this is dangerous medicine, a kind of magic mushroom. So what could be worse than a deluded bot? I say, letting a monkey play could be worse. And monkeys' play is what you get from an mc bot when all possible moves come back with indistinguishably wonderful or terrible win rates. Adding a wishful (or pessimistic) komi will distort reality, but will help create bigger win rate differences between moves. It should be possible to assign costs to both dynamic komi and to insufficiently spreading win rates between moves. My hypothesis is, that with unstable groups on the board, the win-rate spread will tend to be larger then with stable groups. So with proper balancing, the bot should refuse to take dynamic komi when he sees a chance to win outright. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] memory management for search trees(basic question)
> Thanks for the replies. I will most likely be writing in C++ ... If you've not already, rush out and buy Effective C++ by Scott Meyers. Item 10 shows you a memory pool, items 1..9 and 11..50 will also come in useful. As will More Effective C++, and Effective STL. Boost has a memory pool library (*). I use boost/detail/quick_allocator.hpp (and if you are familiar with Boost, the "detail/" means an unsupported library whose interface may change without warning) which was quickest as long as I disabled thread support. If you are planning to have multiple threads share the same memory pool I suggest the main boost pool library (*), as I'm sure they've taken care of the issues, while never losing sight of efficiency. Darren *: http://www.boost.org/doc/libs/1_39_0/libs/pool/doc/index.html -- Darren Cook, Software Researcher/Developer http://dcook.org/gobet/ (Shodan Go Bet - who will win?) http://dcook.org/mlsn/ (Multilingual open source semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Dynamic komi in commercial programs
So changing the komi doesn't actually improve your confidence interval. If (as Darren said) the win percentage is a crude estimate of the final score, then changing komi would do nothing to change the results one got (and at extremes biases it badly). Moving the ratios closer to 50/50 (by whatever means) at the high end changes the variance of the data, and in a world where there's a 1:1 correspondence between score and win ratio does nothing to change one's confidence that the highest ranked node should be. Of note there is that the goal, of any method chosen, is to make the ranking of individual moves as accurate as possible. It can do that by either increasing the number of simulations or by increasing the granularity of the metric. This second point seems more like a testbed for that sigmoid function paper than for dynamic komi, but that's just my guess. Of course what would be most preferable would be lots of data. Arguing with guesses instead of data is silly. ~ 2009/7/14 terry mcintyre : > Maybe we should go back to the question which dynamic komi is an attempt to > solve: how to obtain better discrimination when every move seems to be > clustered near "I am so freaking dead" or "I am so far ahead", as the case > may be. > > Terry McIntyre > > “We hang the petty thieves and appoint the great ones to public office.” -- > Aesop > > From: Stefan Kaitschick > To: computer-go > Sent: Tuesday, July 14, 2009 3:17:38 PM > Subject: Re: [computer-go] Re: Dynamic komi in commercial programs > > Dynamic komi in a sense means that the bot is deluding itself on purpose. > Obviously this is dangerous medicine, a kind of magic mushroom. > So what could be worse than a deluded bot? > I say, letting a monkey play could be worse. > And monkeys' play is what you get from an mc bot when all possible moves > come back with indistinguishably > wonderful or terrible win rates. > Adding a wishful (or pessimistic) komi will distort reality, but will help > create bigger win rate differences between moves. > It should be possible to assign costs to both dynamic komi and to > insufficiently spreading win rates between moves. > My hypothesis is, that with unstable groups on the board, the win-rate > spread will tend to be larger then with stable groups. > So with proper balancing, the bot should refuse to take dynamic komi when he > sees a chance to win outright. > > Stefan > > > > ___ > 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] memory management for search trees(basic question)
I have a good number of C++ books but strangely though I use to own Meyers' first 2 books I have sort of misplaced them. Perhaps I should get a couple new copies. I will study the Boost Pool source and see what I can glean from it. The only custom allocator design I have on hand in a book is the one in Modern C++ Design. Thanks. --- On Tue, 7/14/09, Darren Cook wrote: > From: Darren Cook > Subject: Re: [computer-go] memory management for search trees(basic question) > To: "computer-go" > Date: Tuesday, July 14, 2009, 4:05 PM > > Thanks for the replies. I will > most likely be writing in C++ ... > > If you've not already, rush out and buy Effective C++ by > Scott Meyers. > Item 10 shows you a memory pool, items 1..9 and 11..50 will > also come in > useful. As will More Effective C++, and Effective STL. > > Boost has a memory pool library (*). I use > boost/detail/quick_allocator.hpp (and if you are familiar > with Boost, > the "detail/" means an unsupported library whose interface > may change > without warning) which was quickest as long as I disabled > thread support. > > If you are planning to have multiple threads share the same > memory pool > I suggest the main boost pool library (*), as I'm sure > they've taken > care of the issues, while never losing sight of > efficiency. > > Darren > > *: http://www.boost.org/doc/libs/1_39_0/libs/pool/doc/index.html > > > > -- > Darren Cook, Software Researcher/Developer > http://dcook.org/gobet/ (Shodan Go Bet - who will > win?) > http://dcook.org/mlsn/ (Multilingual open source > semantic network) > http://dcook.org/work/ (About me and my work) > http://dcook.org/blogs.html (My blogs and articles) > ___ > 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/
