object oriented chess programming
James Long
This thread is mainly directed at the saltier programmers....
I am considering creating an object oriented version of Tristram
using C++. I know C++ can be slower than the equivalent
C code, but my only goal is to learn something....
Suppose I wanted to create a class containing all the attack
patterns for the various pieces:
------------------------
this is the "attack.h" file
class AttackBoard
{
public:
AttackBoard(); // constructor
~AttackBoard(); // destructor
// king, knight, and pawn movement patterns do not depend
// on the state of the board (excepting pins, etc.)
static BitBoard m_bbKingAttacks[64];
static BitBoard m_bbKnightAttacks[64];
static BitBoard m_bbWhitePawnAttacks[64];
static BitBoard m_bbBlackPawnAttacks[64];
// rook, bishop, and queen movement will vary with the state of
// the rank/file they are occupying
static BitBoard m_bbVerticalMoves[64][256];
static BitBoard m_bbHorizontalMoves[64][256];
static BitBoard m_bbUpLDownRDiag[64][256]; // from white's point of
view
static BitBoard m_bbUpRDownLDiag[64][256];
};
------------------------------
I know that for encapsulation to work, the data members should be
private,
but let's keep it simple for this argument.
Now I could initialize the static members in the file "attack.cpp"
like this:
----------------------
#include "attack.h"
BitBoard AttackBoard::m_bbKingAttacks[] =
{
HAND WRITTEN DATA HERE.
};
-------------------------
That is ok I guess, but why can I not write a function to initialize
this data?
If I try this:
------------------------
// attack.cpp
#include "attack.h"
void InitializeAttackBoard (void)
{
// initialization code for static data members here
}
I get all kinds of errors. This means to initialize the static data
members of a class
the programmer has to write all the data out by hand? While this is
possible for
smaller arrays it is not feasible for the m_bbVerticalMoves[64][256]
array.
If I can not initialize m_bbVerticalMoves[][] as static, I could write
some
initialization code in the constructor, but this means I would have to
create
an object of class "AttackBoard" before accessing that data, and I lose
the
convenience of not having to declare an instance.
I thought I could create one object of a global scope (just as I do
basic data
types, by instantiating the object in the globals.cpp file and putting
the
line "extern AttackBoard attboard;" in the globals.h file, and including
the
globals.h file into all the source modules) but this also generates
errors.
The last thing I can think of is to declare an instance in *each* source
module,
but this seems to be such a waste of resources.
Surely there has to be something I'm missing here.
Any help is greatly appreciated!
---
James
http://home.fda.net/~wzrdking
James Long
No need to respond now.... problem solved.
Thanks Pete! :-)
Anders Thulin
In article <34AA7EBA...@fda.net>, James Long <wzrd...@fda.net> wrote:
>This thread is mainly directed at the saltier programmers....
>
>I am considering creating an object oriented version of Tristram
>using C++. I know C++ can be slower than the equivalent
>C code, but my only goal is to learn something....
>
>Suppose I wanted to create a class containing all the attack
>patterns for the various pieces:
If you just want to learn C++, you can start anywhere. But if you
want to learn object-oriented programming, you really should start
with an object analysis.
I strongly suspect you would end up with each piece type as separate
objects, and knowing its own attack patterns.
--
Anders Thulin Anders...@lejonet.se 013 - 23 55 32
Telia Engineering AB, Teknikringen 6, S-583 30 Linkoping, Sweden
Rolf Tueschen
Elisabeth van Aaring <Use-Author-Address-Header@[127.1]> wrote:
>Hi James,
>>This thread is mainly directed at the saltier programmers....
>yes, I am a beginner... :-) You will find my proposal appended.
>AttackBoard::~AttackBoard()
>{
>}
>void AttackBoard::InitializeAttackBoard (void)
>{
> // initialization code for static data members here
> a = 1;
> // you may initialize huge arrays instead of a here...
>}
>-------------------------------------------------------
>Easy, isn't it? If this is not the point you address, let me know.
>Elisabeth
One thing from abroad. You must be joking. If you are a beginner, then
what about me? I'm what? I haven't understood a single line of your
programming blablurbs.
Aha, I see, you are using a computer to cheat me?
Rolf von Hering.
Formerly Pope R.
Dave Fotland
If you want c++ to go fast, a couple of suggestions:
If your destructor has no code in it, leave it out. This will
save a call when you delete an object.
If your constructor is small or empty, add the "inline" keyword
in front of it. Liberally using inline for small member functions
could give a big performance increase.
My chess program is in C++, and gets between 60k and 120k nps on a
pentium II-200 depending on the position, so C++ doesn't have to be
slow. I use microsoft VC++ 5.0.
The big advantage of C++ for me was my productivity, since the compiler
catches most of my coding bugs, and C++ lets me express concepts in
a simpler coding style, and lets me change internal representations
without rewriting very much code. So I have a fast program, that searches
full width to 7 or 8 ply in the middle game, and is rated between 1800 and
2000, after just 6 weeks. It doesn't have much chess knowledge yet, and
I'm not a very strong player (about 1400), so it won't get much stronger,
but it was a fun project. I couldn't have done it so quickly in C. There
would have been much more debugging.
My basic class types are bitmap, chessboard, chessmove, chessgame,
searchengine, transposition table. evaluate and move generate are members
of chessboard. I don't have separate classes for each piece. The chessboard
class knows how the pieces move.
Each chessmove is a 16 bit int, like most programs, but having it a separate
class with inline member functions, makes the rest of the code much
cleaner.
David Fotland
James Long (wzrd...@fda.net) wrote:
: This thread is mainly directed at the saltier programmers....
: I am considering creating an object oriented version of Tristram
: using C++. I know C++ can be slower than the equivalent
: C code, but my only goal is to learn something....
: Suppose I wanted to create a class containing all the attack
: patterns for the various pieces:
: ------------------------
: ------------------------------
: -------------------------
: #include "attack.h"
: void InitializeAttackBoard (void)
: {
: // initialization code for static data members here
: }
: I get all kinds of errors. This means to initialize the static data
: ---
: James
: http://home.fda.net/~wzrdking
--
David Fotland fot...@XXYYZZcup.hp.com Remove XXYYZZ before using
Opinions are my own, not Hewlett Packard's.
Tord Kallqvist Romstad
In article <68trk9$kdp$1...@ocean.cup.hp.com>, Dave Fotland wrote:
>My chess program is in C++, and gets between 60k and 120k nps on a
>pentium II-200 depending on the position, so C++ doesn't have to be
>slow. I use microsoft VC++ 5.0.
>
>The big advantage of C++ for me was my productivity, since the compiler
>catches most of my coding bugs, and C++ lets me express concepts in
>a simpler coding style, and lets me change internal representations
>without rewriting very much code. So I have a fast program, that searches
>full width to 7 or 8 ply in the middle game,
7 or 8 ply seems very little, considering that you get 60-120k nps. Do you
use null moves? Using null moves, you should reach at least 10 ply in the
middle game, if your quiescence search is reasonably efficient and you
don't have too many extensions.
> and is rated between 1800 and 2000, after just 6 weeks.
Not bad. It took me more than six weeks to implement all the rules of chess
in my program, and several months to remove most serious bugs. The GUI is
still unbelievably ugly, this is the main reason that my program is not yet
publicly available. The strength of my program is currently somewhere
between 2000 and 2200, I believe.
>It doesn't have much chess knowledge yet, and
>I'm not a very strong player (about 1400), so it won't get much stronger,
>but it was a fun project.
I don't think you need to be a strong chess player to write a good chess
program. Most of the world class programmers are probably rated below 2000.
By the way, are you the author of Many Faces of Go?
Tord
--
"The true Christian should be aware of mathematicians and those who make
empty prophecies. Chances are already there that mathematicians have
made a covenant with the Devil to confine man in the bounds of Hell"
- St. Augustin
Dave Fotland
Tord Kallqvist Romstad (rom...@priamos.uio.no) wrote:
: In article <68trk9$kdp$1...@ocean.cup.hp.com>, Dave Fotland wrote:
: 7 or 8 ply seems very little, considering that you get 60-120k nps. Do you
: use null moves? Using null moves, you should reach at least 10 ply in the
: middle game, if your quiescence search is reasonably efficient and you
: don't have too many extensions.
So I must have some bugs left in my search. I'm using null move. I extend
one ply on check, or pawn move to 6th or 7th rank. The quiescence search
is all captures and pawn promotions. I do very little move sorting. During
normal search, I search null first, then hash suggested, then 2 killers
per ply, then captures, then rest. During quiescence search, I sort
captures of bigger pieces by smaller pieces first.
I think on the opponent's time by just having the program do a search for
the opponent, rather than just trying his best response. I don't clear
the transposition table between searches, so this search for the opponent's
best move loads up the transposition table and makes the next search fast.
I don't do null move at the root or the leaf, and don't do two null moves
in a row. Can I do better?
My transposition table is small, about 100K entries, two way associative.
7 or 8 ply is at 30 seconds per move. 7 ply usually takes a few million
nodes in the middle game, with about 3/4 in the quiescence search.
Any suggestions for making the Q search more efficient?
: I don't think you need to be a strong chess player to write a good chess
: program. Most of the world class programmers are probably rated below 2000.
: By the way, are you the author of Many Faces of Go?
Yes. I decided I needed a break from computer go, so I wanted to see how
long it would take to write a reasonable chess program. I don't think I
will keep at it until it can competet with the best though.
Robert Hyatt
Dave Fotland <fot...@cup.hp.com> wrote:
: Tord Kallqvist Romstad (rom...@priamos.uio.no) wrote:
: : In article <68trk9$kdp$1...@ocean.cup.hp.com>, Dave Fotland wrote:
: : 7 or 8 ply seems very little, considering that you get 60-120k nps. Do you
: : use null moves? Using null moves, you should reach at least 10 ply in the
: : middle game, if your quiescence search is reasonably efficient and you
: : don't have too many extensions.
: So I must have some bugs left in my search. I'm using null move. I extend
: one ply on check, or pawn move to 6th or 7th rank. The quiescence search
: is all captures and pawn promotions. I do very little move sorting. During
: normal search, I search null first, then hash suggested, then 2 killers
: per ply, then captures, then rest. During quiescence search, I sort
: captures of bigger pieces by smaller pieces first.
: I think on the opponent's time by just having the program do a search for
: the opponent, rather than just trying his best response. I don't clear
: the transposition table between searches, so this search for the opponent's
: best move loads up the transposition table and makes the next search fast.
: I don't do null move at the root or the leaf, and don't do two null moves
: in a row. Can I do better?
: My transposition table is small, about 100K entries, two way associative.
: 7 or 8 ply is at 30 seconds per move. 7 ply usually takes a few million
: nodes in the middle game, with about 3/4 in the quiescence search.
: Any suggestions for making the Q search more efficient?
first is to order the captures better, then you can start getting
more speculative by not trying captures that won't bring the score
back up close enough to alpha so that the evaluation has a chance
of producing a score large enough to not fail low. If you do this,
you can reduce your q-search by 1/2, easily. IE, first, don't try
captures that obviously lose. I use a static exchange evaluator
to compute this...
: : I don't think you need to be a strong chess player to write a good chess
: : program. Most of the world class programmers are probably rated below 2000.
: : By the way, are you the author of Many Faces of Go?
: Yes. I decided I needed a break from computer go, so I wanted to see how
: long it would take to write a reasonable chess program. I don't think I
: will keep at it until it can competet with the best though.
: --
: David Fotland fot...@XXYYZZcup.hp.com Remove XXYYZZ before using
: Opinions are my own, not Hewlett Packard's.
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
Tord Kallqvist Romstad
In article <691875$rcv$2...@ocean.cup.hp.com>, Dave Fotland wrote:
>Tord Kallqvist Romstad (rom...@priamos.uio.no) wrote:
>: In article <68trk9$kdp$1...@ocean.cup.hp.com>, Dave Fotland wrote:
>
>: 7 or 8 ply seems very little, considering that you get 60-120k nps. Do you
>: use null moves? Using null moves, you should reach at least 10 ply in the
>: middle game, if your quiescence search is reasonably efficient and you
>: don't have too many extensions.
>
>So I must have some bugs left in my search. I'm using null move. I extend
>one ply on check, or pawn move to 6th or 7th rank. The quiescence search
>is all captures and pawn promotions. I do very little move sorting. During
>normal search, I search null first, then hash suggested, then 2 killers
>per ply, then captures, then rest. During quiescence search, I sort
>captures of bigger pieces by smaller pieces first.
You should try the captures _before_ the killers. This is usually much
faster. It would probably also be a good idea to use the history heuristic
(please ask if you don't know what I mean, and I will explain the idea).
The idea is trivial to implement, and generally reduces the tree size a lot.
Your extensions seem OK. It is probably best to consider only _safe_ pawn
moves to the 6th or 7th rank. There is not much point in extending pawn moves
when the pawn can be captured immediately.
>I think on the opponent's time by just having the program do a search for
>the opponent, rather than just trying his best response. I don't clear
>the transposition table between searches, so this search for the opponent's
>best move loads up the transposition table and makes the next search fast.
I haven't tried your approach, but I think the normal method would perform
slightly better.
>I don't do null move at the root or the leaf, and don't do two null moves
>in a row. Can I do better?
>
>My transposition table is small, about 100K entries, two way associative.
>7 or 8 ply is at 30 seconds per move. 7 ply usually takes a few million
>nodes in the middle game, with about 3/4 in the quiescence search.
>
>Any suggestions for making the Q search more efficient?
Call your evaluation function before generating the captures. If
eval + captured_piece is much less than alpha, don't include the capture in
the quiescence search (in my program "much less" is half a pawn). Another
idea is to make a swapoff function. Designing an efficient swapoff routine
is not easy, but it makes the Q search much faster, and can also be used
to improve your move ordering. Most of the top programs use a swapoff
function, I believe.
By the way, in my first answer to you I thought you searched 7 or 8 ply
at tournament time controls (3 min/move). At 30 seconds per move 7-8 ply
isn't that bad, but you should still be able to search a ply or two deeper.
>: By the way, are you the author of Many Faces of Go?
>
>Yes. I decided I needed a break from computer go, so I wanted to see how
>long it would take to write a reasonable chess program. I don't think I
>will keep at it until it can competet with the best though.
I guess computer go is very different from computer chess. Do you use some
of the same techniques? Would it be worthwile for chess programmers to
study computer go as well?
Dave Fotland
Tord Kallqvist Romstad (rom...@kassandra.uio.no) wrote:
: In article <691875$rcv$2...@ocean.cup.hp.com>, Dave Fotland wrote:
: >Tord Kallqvist Romstad (rom...@priamos.uio.no) wrote:
: >: In article <68trk9$kdp$1...@ocean.cup.hp.com>, Dave Fotland wrote:
: You should try the captures _before_ the killers. This is usually much
: faster. It would probably also be a good idea to use the history heuristic
: (please ask if you don't know what I mean, and I will explain the idea).
: The idea is trivial to implement, and generally reduces the tree size a lot.
Thanks. I just haven't gotten around yet to trying the history heuristic.
I did find a couple of bugs in my search once you pointed out it was
too slow. I'll move the killers after the captures. I experimented with
having null move set alpha if it returns a value > alpha but less than
beta. Crafty doesn't do this, but it made the search tree smaller. I
suppose there is some reason not to do this?
And many thanks to Bob Hyatt for his suggestions as well. I use bitboards
for pieces, but not rotated bitboards. Move generation is fast enough
without them, and I'm not using attckfrom or attackto in the evaluation,
which seems to be the big win for them.
: Your extensions seem OK. It is probably best to consider only _safe_ pawn
: moves to the 6th or 7th rank. There is not much point in extending pawn moves
: when the pawn can be captured immediately.
: >I think on the opponent's time by just having the program do a search for
: >the opponent, rather than just trying his best response. I don't clear
: >the transposition table between searches, so this search for the opponent's
: >best move loads up the transposition table and makes the next search fast.
: I haven't tried your approach, but I think the normal method would perform
: slightly better.
I'm thinking of games where the time control is wildly unbalanced. The
user will give the program a few minutes for the game, but will think a long
time. Then my way of thinking on his time will likely find a better move
for him that would have been used with the traditional method. If I
make a product, it will be aimed at weaker players, who won't want to
wait for the computer. I'm not trying to win in even-time tournaments
against strong programs, since I have to go back to computer go next month.
Also, my approach was a little easier to code :)
: Call your evaluation function before generating the captures. If
: eval + captured_piece is much less than alpha, don't include the capture in
: the quiescence search (in my program "much less" is half a pawn). Another
: idea is to make a swapoff function. Designing an efficient swapoff routine
: is not easy, but it makes the Q search much faster, and can also be used
: to improve your move ordering. Most of the top programs use a swapoff
: function, I believe.
Wow, only half a pawn. What if making the capture discovers a check or
a bigger capture to compensate? I do this, but with much less set to
about 5 pawns I think.
: By the way, in my first answer to you I thought you searched 7 or 8 ply
: at tournament time controls (3 min/move). At 30 seconds per move 7-8 ply
: isn't that bad, but you should still be able to search a ply or two deeper.
I don't have the patience to play test games at tournament time controls.
All my games are at 30 sec per move or faster.
: I guess computer go is very different from computer chess. Do you use some
: of the same techniques? Would it be worthwile for chess programmers to
: study computer go as well?
Very different. Brute force search is impossible, and accurate evaluation
is very slow. Most top programs only evaluate the full board at about
10 nps. Most look at only about 10 moves at the full board (out of about
300 possible), and search most moves only a few ply, but some moves very
deeply, maybe 15 ply.
To evaluate the full board, programs have to calculate the results of local
fights. Even here full width search is not possible, since you often have
to look 10 to 20 ply deep to see what any weak amateur can figure out.
MF's local tactical engine does about 30k nps, prunes to 2-5 moves per
ply (out of maybe 10-20 possible), and typically looks 15 ply deep
on some lines, and a few lines in each search are over 40 ply deep.
So computer go is interesting if you want to see the results of highly
selective search, directed by a large amount of knowledge.
The results are similar to this style of chess program. Many years of
work to fine tune the knowledge, and the result is a player of
middle of the road amateur strength (perhaps like a 1500 ches player).
But in computer go there seems to be no other simple alternative, like
the search techniques develped for computer chess :(
There is specialized Go software that just solves local tactical problems
using alpha-beta iterative deepening, just like chess, on restricted
partial board areas. These perform quite well, and the top one, GoTools,
is mid professional strength.
Robert Hyatt
Dave Fotland <fot...@cup.hp.com> wrote:
: Thanks. I just haven't gotten around yet to trying the history heuristic.
: I did find a couple of bugs in my search once you pointed out it was
: too slow. I'll move the killers after the captures. I experimented with
: having null move set alpha if it returns a value > alpha but less than
: beta. Crafty doesn't do this, but it made the search tree smaller. I
: suppose there is some reason not to do this?
The reason is this: 99.99% of the nodes I search in Crafty are searched
with the window (alpha,alpha+1) because I use PVS. So either null-move
fails high and I return beta, or it doesn't and I don't get a better
estimate of alpha because alpha is as high as it can be without clipping
over beta...
: And many thanks to Bob Hyatt for his suggestions as well. I use bitboards
: for pieces, but not rotated bitboards. Move generation is fast enough
: without them, and I'm not using attckfrom or attackto in the evaluation,
: which seems to be the big win for them.
one other win for them is q-search, because I can generate *only* capture
moves without having to skip over empty squares.
: I'm thinking of games where the time control is wildly unbalanced. The
: user will give the program a few minutes for the game, but will think a long
: time. Then my way of thinking on his time will likely find a better move
: for him that would have been used with the traditional method. If I
: make a product, it will be aimed at weaker players, who won't want to
: wait for the computer. I'm not trying to win in even-time tournaments
: against strong programs, since I have to go back to computer go next month.
good idea for unbalanced time controls...
Tord Kallqvist Romstad
In article <695oit$opf$1...@ocean.cup.hp.com>, Dave Fotland wrote:
>: Call your evaluation function before generating the captures. If
>: eval + captured_piece is much less than alpha, don't include the capture in
>: the quiescence search (in my program "much less" is half a pawn). Another
>: idea is to make a swapoff function. Designing an efficient swapoff routine
>: is not easy, but it makes the Q search much faster, and can also be used
>: to improve your move ordering. Most of the top programs use a swapoff
>: function, I believe.
>
>Wow, only half a pawn. What if making the capture discovers a check or
>a bigger capture to compensate? I do this, but with much less set to
>about 5 pawns I think.
You are right, excluding some captures from the Q search will always make
you overlook some tactics. I believe that this is more than compensated by
the tactics you find because of the increased search depth. I haven't
experimented much with this, however, so I might be wrong. Bob, what do
you think?
>: I guess computer go is very different from computer chess. Do you use some
>: of the same techniques? Would it be worthwile for chess programmers to
>: study computer go as well?
>
>Very different. Brute force search is impossible, and accurate evaluation
>is very slow. Most top programs only evaluate the full board at about
>10 nps. Most look at only about 10 moves at the full board (out of about
>300 possible), and search most moves only a few ply, but some moves very
>deeply, maybe 15 ply.
>
>To evaluate the full board, programs have to calculate the results of local
>fights. Even here full width search is not possible, since you often have
>to look 10 to 20 ply deep to see what any weak amateur can figure out.
>MF's local tactical engine does about 30k nps, prunes to 2-5 moves per
>ply (out of maybe 10-20 possible), and typically looks 15 ply deep
>on some lines, and a few lines in each search are over 40 ply deep.
Very interesting. This reminds me very much of a computer chess idea I had a
couple of years ago. The idea is to try to emulate the way a strong human
chess player would use a chess program for analysis of a position. At every
node in the search tree, the algorithm does the following:
1. Use a _very_ fast, Deep Blue-like tactical engine to search for immediate
wins for the side to move.
2. If no forced win is found, use an advanced candidate move generator to
select a few candidate moves based on positional criterions.
The algorithm does a normal alpha-beta search, but only searches the moves
found in step 2 above. I have never tried out this idea, because it seems
to require extremely fast hardware to work well. Bob once told me that my
idea was similar to the B* search algorithm, which I unfortunately haven't
been able to find any information. Could you please explain something about
this algorithm, Bob? Has it ever been tried out in a chess program?
If I have understood your description correctly, it seems that the typical
go playing program uses an algorithm similar to what I described above.
Am I right?
>So computer go is interesting if you want to see the results of highly
>selective search, directed by a large amount of knowledge.
>
>The results are similar to this style of chess program. Many years of
>work to fine tune the knowledge, and the result is a player of
>middle of the road amateur strength (perhaps like a 1500 ches player).
>But in computer go there seems to be no other simple alternative, like
>the search techniques develped for computer chess :(
I guess that ruins my hopes of ever writing a strong go program. I am
a weak go player (about 5-10 kyu, I believe). It seems that good knowledge
of the game is more important in go programming than in chess programming.
>There is specialized Go software that just solves local tactical problems
>using alpha-beta iterative deepening, just like chess, on restricted
>partial board areas. These perform quite well, and the top one, GoTools,
>is mid professional strength.
How fast are programs like GoTools? Would it be possible (now or in the
near future) to include someting like GoTools in a normal go-playing
program? The tactical abilities of the best go programs do not impress me.
(I hope you are not offended by my last sentence. I have great respect for
go programmers, who do something incredibly much more difficult than we
chess programmers do).
Robert Hyatt
Tord Kallqvist Romstad <rom...@filoktetes.uio.no> wrote:
: In article <695oit$opf$1...@ocean.cup.hp.com>, Dave Fotland wrote:
:>: Call your evaluation function before generating the captures. If
:>: the quiescence search (in my program "much less" is half a pawn). Another
:>: idea is to make a swapoff function. Designing an efficient swapoff routine
:>: is not easy, but it makes the Q search much faster, and can also be used
:>: to improve your move ordering. Most of the top programs use a swapoff
:>: function, I believe.
:>
:>Wow, only half a pawn. What if making the capture discovers a check or
:>a bigger capture to compensate? I do this, but with much less set to
:>about 5 pawns I think.
: You are right, excluding some captures from the Q search will always make
: you overlook some tactics. I believe that this is more than compensated by
: the tactics you find because of the increased search depth. I haven't
: experimented much with this, however, so I might be wrong. Bob, what do
: you think?
I do it too, so I'm apparently in your camp. :)
Dave Fotland
: >So computer go is interesting if you want to see the results of highly
: >selective search, directed by a large amount of knowledge.
: >
: >The results are similar to this style of chess program. Many years of
: >work to fine tune the knowledge, and the result is a player of
: >middle of the road amateur strength (perhaps like a 1500 ches player).
: >But in computer go there seems to be no other simple alternative, like
: >the search techniques develped for computer chess :(
: I guess that ruins my hopes of ever writing a strong go program. I am
: a weak go player (about 5-10 kyu, I believe). It seems that good knowledge
: of the game is more important in go programming than in chess programming.
As you write the program you will become a stronger player. The top
program, Handtalk, is written by a strong chinese 6 dan. But the other
strong programs are written by 2 dan to 5 dan players. I was 15 kyu when
I started Many Faces, but was 1 dan before it really got strong. So
I don't think it is that different from Chess. I don't know that a 3 dan
go player writing a program (me), has more knowledge of go relative to
a 2200 chess player writing a chess program has of chess.
: >There is specialized Go software that just solves local tactical problems
: >using alpha-beta iterative deepening, just like chess, on restricted
: >partial board areas. These perform quite well, and the top one, GoTools,
: >is mid professional strength.
: How fast are programs like GoTools? Would it be possible (now or in the
: near future) to include someting like GoTools in a normal go-playing
: program? The tactical abilities of the best go programs do not impress me.
: (I hope you are not offended by my last sentence. I have great respect for
: go programmers, who do something incredibly much more difficult than we
: chess programmers do).
Gotools is pretty fast - solves most problems in a few seconds. When I
say it is professional strength, I mean it can solve problems in the same
time limits. It's problem is that it only knows life and death. Problems
must be completely enclosed, and it finds the "one" answer, as life and
death problems only have one answer. In a real game, there are liberty
fights, threats to connect out, and other similar things in real game
tactics that gotools can't answer. In games, also there are usually several
moves that work, and you have to find them all, so full boardsearch can
pick the best one.
I work on my life/death analyzer from time to time, but is not the weakest
part of the program, so improving it doesn't help the overall strength
much.
David
: Tord
: --
: "The true Christian should be aware of mathematicians and those who make
: empty prophecies. Chances are already there that mathematicians have
: made a covenant with the Devil to confine man in the bounds of Hell"
: - St. Augustin
--