View Single Post
  #7   Report Post  
Old May 3rd 04, 08:00 AM
pd42
 
Posts: n/a
Default Chess program testing

Noah Roberts wrote in message ...
pd42 wrote:
Hi,

I have written a very small chess program in Visual Basic (using Excel
as interface). It's only a couple of hundred lines of VB code. Don't
start laughing now, this was only to get aquainted with the most
important principles of chess programming (data structures,
evaluation, tree search and move generation). This Excel program
actually plays decent chess, using alpha-beta pruning and iterative
deepening, that's it (no quiscence search, no hash tables, no opening
books, a very simple evaluation function and vector representation of
the chess board).


I could be wrong, but I don't believe iterative deepening actually works
unless there is a transposition table to record results of previous
iterations. Iterative deepening is meant to increase the likelihood of
perfect move ordering for the search by filling the TTable with good
moves. Unless you are recording results somehow, and the ttable is the
most direct method, you are simply wasting time.

It's rating is probably somewhere around 1000 or so
(due to the computation speed and other VB limitations I can't go
deeper than 5 plies without crashing :-(


Yes, VB is not a very good language.

Now I want to start using Visual C++ (I'm new to C, C++, but not to
programming), and my quesiotn is: as soon as this program starts
playing chess I would like to test it against other human players, is
there a possibility to do that, how?


First, make sure to follow the xboard protocol. Second use the Zippy(?)
program to connect to FICS with a computer account. Then wait for the
results. You might also have options with the UCI protocol, but I am
not familiar with them.

Another related question: any idea of the relation between rating and
depth of search? In other words: if a program has strength X, how much
will this improve by searching one ply deeper?


So far, one ply of depth has surpassed any strength gained in knowledge.
At least this was the result of one engine - Hitech(?).


That is what I would have guessed! My program philosophy is as
follows:
1) The evaluation function should be kept as simple as possible
(=fast), strictly evaluating the STATIC properties of a position (=
mainly material balance).
2) The DYNAMIC properties of a position are being taken care of by the
tree search.
3) To compensate for a limited search depth, two or three positional
properties could be included in the evaluation function (like pawn
structure and king safety, optionally: location of rooks, knights,
....).
4) If 'king safety' is 'properly defined', this strategy can also work
in endgames.