Wasn't Gifu to most prominent computer go tournament in the world? If
so that's very sad news.
From a chess guy that's like hearing there wont be a WCCC, Paderborn, or Mainz.
Hopefully funding can be raised for next year.
-Josh
On 7/21/07, Hiroshi Yamashita <[EMAIL PROTECTED]> wrote:
Unfortu
Unfortunately, this year's Gifu Challenge was cancelled for
financial difficulty. Gifu Challenge was a computer Go tournament
that had been held four times since 2003. It was held in autumn
season. "Gifu" is a prefecture name in Japan.
last year's result. (there is no information about cancel)
Apparently there are more hardware issues with CGOS. The machine is
down right now. So it will be a few hours before I can bring the
software back up.
Sorry about the problems.
- Don
___
computer-go mailing list
computer-go@computer-go.org
http://w
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
__
20x22 is also a popular choice, since in a single dimension array a single
entry worked for other off-right and off-left points. Goliath used this. I
didn't have any real reason to use 19x19 other than smaller size, since the
whole program had to fit in 640 KB :(
I have an array of offsets to ad
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
The initial patterns are, of course, bitmaps of the board. When a nonzero
signal finally arrives at cell #5, one of the 1-bits is randomly selected
as the move. (If that turns out illegal, the actual move is "pass.")
Without understanding everything about what you're doing (not even
close), I'm
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
George Dahl said:
> FANN (http://leenissen.dk/fann/) is a great neural network library
> written in C. I don't know much about books on *programming* neural
> networks specifically, but I know of many great books on neural
> networks. I am a big fan of Bishop's Neural Networks for Pattern
> Recog
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 7/20/07, Joshua Shriver <[EMAIL PROTECTED]> wrote:
Anyone recommend a good book on programming Neural Networks in C or C++?
Been digging around the net for while and haven't come up with
anything other than an encyclopedia-like definition/writeup. No
examples or tutorials.
There are some C
I realize 5pm is probably a really bad time. I picked it out of the air
thinking that it'd be most convenient for those that are participating in
the event. I'm now thinking that those (like me) that drive there and drive
home after a short stay may want to get on the road earlier than that.
I
On 7/16/07, Jason House <[EMAIL PROTECTED]> wrote:
The US Go Congress begins in less than two weeks. I have two questions:
1. If you plan to attend, which days will you be there?
2. Will you be competing? (Not with a bot)
3. Which days are most convenient for a gathering of developers?
Sin
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
FANN (http://leenissen.dk/fann/) is a great neural network library
written in C. I don't know much about books on *programming* neural
networks specifically, but I know of many great books on neural
networks. I am a big fan of Bishop's Neural Networks for Pattern
Recognition even if you aren't n
Anyone recommend a good book on programming Neural Networks in C or C++?
Been digging around the net for while and haven't come up with
anything other than an encyclopedia-like definition/writeup. No
examples or tutorials.
Thanks!
-Josh
___
computer-go
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
terry mcintyre wrote:
An interesting recap of how the hype can sometimes far outpace the reality:
http://www.cs.ualberta.ca/~chinook/project/legacy.html
I liked this quote from Robert Nealey, which I think is applicable to go
as well;
By sticking to its programmed instructions, it may find
37 matches
Mail list logo