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
On Tue, Jul 14, 2009 at 4:07 AM, Ingo Althöfer 3-hirn-ver...@gmx.dewrote:
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
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
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
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
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
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
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
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
- Original Message -
From: Dave Dyer dd...@real-me.net
To: computer-go computer-go@computer-go.org
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
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 terrymcint...@yahoo.com
“We hang the petty
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
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
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
14 matches
Mail list logo
