When I started I used this as well. However when I realized how many
times I would be looking at all adjacent intersections I switched to
having an array adjacent[BOARD_SIZE * BOARD_SIZE][5]. In addition to
making the code cleaner, this allows for more compact code size and (I
think) more predicta
> 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
__
On Behalf Of Darren Cook
> Sent: Friday, July 20, 2007 5:17 PM
> To: computer-go
> Subject: Re: [computer-go] Go datastructures
>
>
> > 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 els
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 n
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
row
>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
> 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
off
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 bo
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-
>> cas
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 conne
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
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
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 m
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 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
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 usi
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
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 concept
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 nit-picki
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 no
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
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, plug>Data Structures and Algorithms in Java.
M
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 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
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 about
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
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
h
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 parent;
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
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
_
30 matches
Mail list logo
