What a timely thread!
I've reimplemented Łukasz Lew's libego in Java for the latest edition
of Orego. It includes something of an explanation of the data
structures. I believe the code itself is relatively clear.
The goodies are here:
http://www.lclark.edu/~drake/go/
Enjoy!
Peter Drake
Quoting Joshua Shriver [EMAIL PROTECTED]:
What kind of data structures do you all use for your engines, in
respect to board representation and move generation. I know in chess
bitboard, mailbox board[8][8], 0x88 exist all with their pro's and
cons. Are there similar concepts for Go?
I always
Thanks for the documentation. I have a few questions.
Looking at only the four neighbors to detect eye-like points seems like it
could leave many false eyes and allow captures of dangling chains. Is there
any mechanism to avoid this problem in the play of the bot?
I'll have to think more
On Jul 20, 2007, at 7:23 AM, Jason House wrote:
Thanks for the documentation. I have a few questions.
Looking at only the four neighbors to detect eye-like points seems
like it could leave many false eyes and allow captures of dangling
chains. Is there any mechanism to avoid this problem
On 7/20/07, Peter Drake [EMAIL PROTECTED] wrote:
On Jul 20, 2007, at 7:23 AM, Jason House wrote:
Thanks for the documentation. I have a few questions.
Looking at only the four neighbors to detect eye-like points seems like it
could leave many false eyes and allow captures of dangling chains.
On Jul 20, 2007, at 8:04 AM, Jason House wrote:
I thought he was using the disjoint set! I'll recheck. Well
written disjoint sets average out to nearly O(1) operations for
everything.
Yes -- O(log* n) to be precise, as mentioned in my book, shameless
plugData Structures and Algorithms
On 7/20/07, Peter Drake [EMAIL PROTECTED] wrote:
On Jul 20, 2007, at 8:04 AM, Jason House wrote:
I thought he was using the disjoint set! I'll recheck. Well
written disjoint sets average out to nearly O(1) operations for
everything.
Yes -- O(log* n) to be precise, as mentioned in my
Yes: log* is to log what log is to division. In other words, it's the
number of times you have to take a logarithm before you get down to
1. It's an extremely slowly-growing function.
It's conceivable that actual, empirical time is a better metric than
asymptotic time here, because we're
Peter Drake wrote:
On Jul 20, 2007, at 8:04 AM, Jason House wrote:
I thought he was using the disjoint set! I'll recheck. Well written
disjoint sets average out to nearly O(1) operations for everything.
Yes -- O(log* n) to be precise, ...
At the risk of being accused of serious
On Jul 19, 2007, at 8:16 PM, Joshua Shriver wrote:
Greetings,
What kind of data structures do you all use for your engines, in
respect to board representation and move generation. I know in chess
bitboard, mailbox board[8][8], 0x88 exist all with their pro's and
cons. Are there similar
On 7/20/07, Ian Osgood [EMAIL PROTECTED] wrote:
My beginner UCT program (http://www.quirkster.com/forth/fgp.html)
uses bitboards because it is very simple to express the rules of Go
using bit operations. However, a mailbox board which contains
references into string objects which incrementally
It looks like you're right -- but I did say O (rather than THETA), so
I'm also technically correct. :-)
Peter Drake
http://www.lclark.edu/~drake/
On Jul 20, 2007, at 9:15 AM, Richard J. Lorentz wrote:
Peter Drake wrote:
On Jul 20, 2007, at 8:04 AM, Jason House wrote:
I thought he was
On Jul 20, 2007, at 8:04 AM, Jason House wrote:
On 7/20/07, Peter Drake [EMAIL PROTECTED] wrote:
On Jul 20, 2007, at 7:23 AM, Jason House wrote:
Thanks for the documentation. I have a few questions.
Looking at only the four neighbors to detect eye-like points seems
like it could leave
Jason House said:
Thanks for the documentation. I have a few questions.
Looking at only the four neighbors to detect eye-like points seems like
it could leave many false eyes and allow captures of dangling chains.
Is there any mechanism to avoid this problem in the play of the bot?
Eye
On 7/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Jason House said:
Thanks for the documentation. I have a few questions.
Looking at only the four neighbors to detect eye-like points seems like
it could leave many false eyes and allow captures of dangling chains.
Is there any
On Jul 20, 2007, at 10:58 AM, Jason House wrote:
On 7/20/07, Ian Osgood [EMAIL PROTECTED] wrote:
My beginner UCT program (http://www.quirkster.com/forth/fgp.html)
uses bitboards because it is very simple to express the rules of Go
using bit operations. However, a mailbox board which contains
2007/7/20, Ian Osgood [EMAIL PROTECTED]:
Looking at only the four neighbors to detect eye-like points seems like it
could leave many false eyes and allow captures of dangling chains. Is there
any mechanism to avoid this problem in the play of the bot?
It does also look at the diagonals; see
On Jul 20, 2007, at 2:25 PM, Andrés Domínguez wrote:
2007/7/20, Ian Osgood [EMAIL PROTECTED]:
My program disallows playing in eyes (string of empty surrounded
by self)
unless a neighboring stone is in atari. That catches your special-
case, but
is not good for saving tails (strings
From: Ian Osgood [EMAIL PROTECTED]
On Jul 20, 2007, at 2:25 PM, Andrés Domínguez wrote:
2007/7/20, Ian Osgood [EMAIL PROTECTED]:
My program disallows playing in eyes (string of empty surrounded
by self)
unless a neighboring stone is in atari. That catches your special-
case, but
is not
At 08:38 PM 7/19/2007, you wrote:
In the engine I've been working on for a week or two (I'm brand new to
computer-go)
I use:
typedef int INTERSECTION;
typedef enum { BLACK, WHITE, EMPTY } COLOR;
i used: typedef enum { BLACK, WHITE, EMPTY,OFFBOARD } COLOR; once. it
eliminated tests for array
I always used a 1-dimensional 25x25 = 625 integer array with 0 for
black 1 for white 2 for empty and 3 for border (everything else).
This way I can have a 21x21 board with 2 rows of border cells
surrounding it.
David Fotland, on the other hand, seems to use a 19x19 grid, and detect
it
has functions to turn a 0..N coord into x and y coords, functions to
rotate points, functions to return the coord a certain distance away
(e.g. ikken to the North, keima to the South-East).
Okay, I've got functions that detect a certain relation between
stones--and can be linked together to
On Jul 20, 2007, at 12:10 PM, Jason House wrote:
That's essentially the best that I came up with. Since bit board
operations on 19x19 are slow...
They are not necessarily slower than on smaller boards if you store
only non-zero portions of your bitmaps along with the start and end
When we deal with patterns and their rotations/reflections, we have a
canonical version that contains everything we care about, and all of
the R/R patterns have pointers to the canonical. If these are being
generated by some automated algorithm, we generate all of the R/R
as soon as we see the
I don't use functions to convert 0-n to x, y. I use arrays of constants
instead. It's faster.
APD.get_x(d), for instance, is doing a lookup in an array that is made
by the constructor once when the program starts up. Everything is inline
so it is the same.
Darren
Greetings,
What kind of data structures do you all use for your engines, in
respect to board representation and move generation. I know in chess
bitboard, mailbox board[8][8], 0x88 exist all with their pro's and
cons. Are there similar concepts for Go?
-Josh
2007/7/20, Joshua Shriver [EMAIL PROTECTED]:
What kind of data structures do you all use for your engines, in
respect to board representation and move generation. I know in chess
bitboard, mailbox board[8][8], 0x88 exist all with their pro's and
cons. Are there similar concepts for Go?
Below
In the engine I've been working on for a week or two (I'm brand new to
computer-go)
I use:
typedef int INTERSECTION;
typedef enum { BLACK, WHITE, EMPTY } COLOR;
struct GROUP
{
INTERSECTION base;
COLOR color;
int count;
int liberties;
INTERSECTION children[5];
INTERSECTION
28 matches
Mail list logo
