Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"How to write a computer chess program"

92 views
Skip to first unread message

Robert Hyatt

unread,
Apr 4, 1996, 3:00:00 AM4/4/96
to

It has been suggested, on several occasions, that I "volunteer" to
undertake writing a book on the above subject. I've been giving this
a lot of thought, and thought I'd query this group on the subject.

Topics might include:

Move generation, using both bitmaps and the now common "X88"
algorithm.

hashing, including managing the key, what to put in the table,
how to use the information from the table, etc... Monty Newborn
and I were discussing writing a paper titled (maybe) "hashing
difficulties" and describing some of the many anomalies that
hashing causes, that would cause a new programmer to spend days
or weeks debugging something that is perfectly normal.

evaluation, with particular attention to bitmap tricks, but
covering specific "things" that an evaluation can do, including
(say) things like very large positional scores and the benefits
and problems they produce.

tree searching using the now infamous negamax recursive
implementation, showing how to test for repetitions, look things
up in the hash table, how to extend the search for certain types
of positions, etc.

quiescence searching, including how/what to include, tricks that
make it much faster, etc.

SEE (Static Exchange Evaluation) and how to code it using an
offset (array) representation of the chessboard, as well as using
a bitmap representation.

Move ordering, including things like captures, killers, history,
hash table move, refutation moves, and so forth.

In short, the idea would be to take what is generally considered
"state of the art" and put it in one book. Currently, there's no
one place you can go to to figure out how a hash table works, or
when some of us mention SEE or MVV/LVA, you can't go to the same
place and figure out what they are.

Before I give much more consideration to the idea, I thought I'd
query those most interested in computer chess. Note that I doubt
I'd write this "on my own" but would likely recruit a lot of help,
people like Monty Newborn, perhaps Ken Thompson, etc. would make
good contributors.

Note that I'm not looking for firm customer offers here. :) just
a "test the water" to see if most agree that such a thing would be
useful. There are a few such books out, but they leave out almost
*all* of the important details and implementation specifics.

Bob
--
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

Andreas De Troy

unread,
Apr 4, 1996, 3:00:00 AM4/4/96
to
news:4k0o22$5...@pelham.cis.uab.edu

hy...@cis.uab.edu (Robert Hyatt) wrote:
>
>It has been suggested, on several occasions, that I "volunteer" to
>undertake writing a book on the above subject. I've been giving this
>a lot of thought, and thought I'd query this group on the subject.
>
> ....

Such a book would be a great idea!

I am currently trying to write a chess-program and I find it really hard
to study the inner workings of programs like Crafty, GNUChess etc., even
with the comments that are given. It is not a lack of C-experience, it is
just to much in one time.

It would be very handy if one could explain the
"state-of-the-art" algorithms (and the previous ones too), especially
someone with your programming-experience, in a book. I would buy it
immediately and read it with great interest. So I would say, Bob, the
sooner the better!!!


Jan Eric Larsson

unread,
Apr 4, 1996, 3:00:00 AM4/4/96
to
Robert Hyatt writes:
>It has been suggested, on several occasions, that I "volunteer" to
>undertake writing a book on the above subject. I've been giving this
>a lot of thought, and thought I'd query this group on the subject.

Go ahead and write, and the world of chess programmers will be
eternally grateful, (including Lang et al of course).

>Note that I'm not looking for firm customer offers here. :)

OK, you have managed to talk me into it. Sign me up for one :-)


Jan Eric Larsson
Knowledge Systems Laboratory, Stanford University, Room 248, M/C 9020
Gates Computer Science Building 2A, Stanford, CA 94305, USA
Phone: +1 415 725 3859, Fax: +1 415 725 5850, E-mail: Lar...@KSL.Stanford.Edu

Tom Kerrigan

unread,
Apr 4, 1996, 3:00:00 AM4/4/96
to
I have found that the demand for a chess program "how to" book is amazing. Bob,
you list a number of topics I would consider relatively advanced. I think a simple
tutorial would have more effect, and if the reader wants more information he can
find it in an ICCA journal (or somewhere). Anyway, if you ever decide to write
something and need some help, feel free to ask me to write a chapter or two.
Probably not about the evaluation function, but you get the idea. :)

Cheers,
Tom

MANOHARARAJAH VALAVAN

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
In article <4k0o22$5...@pelham.cis.uab.edu>,

Robert Hyatt <hy...@cis.uab.edu> wrote:
>
>It has been suggested, on several occasions, that I "volunteer" to
>undertake writing a book on the above subject. I've been giving this
>a lot of thought, and thought I'd query this group on the subject.
>

I would love to see a book like this. I have tried, in the past, to write
a chess program but found very little success. Such a book would be
ideal as a guide.
--
-------------------------------------------------------------------------------
man...@ecf.utoronto.ca | 3rd year Comp Eng., University of Toronto
Valavan Manohararajah |
-------------------------------------------------------------------------------

Anders Thulin

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
In article <4k0o22$5...@pelham.cis.uab.edu>,
Robert Hyatt <hy...@cis.uab.edu> wrote:
>
>It has been suggested, on several occasions, that I "volunteer" to
>undertake writing a book on the above subject. I've been giving this
>a lot of thought, and thought I'd query this group on the subject.

As long as you won't call it "The Dum-dum's guide to computer
chess', 'Tricks of the computer chess masters', or 'Crafty Unleashed',
I don't think you'll have anything to worry about :-)

>Topics might include:
>
>Move generation, using both bitmaps and the now common "X88"
>algorithm.

>[...]

One thing I often find useful, but very rarely is presented
anywhere, is what to avoid and why. What didn't work? What might seem
to be a good idea, but turns out to be problematical? Those details
usually give a better grasp of the 'shape' of the problem/solution:
not only foreground (what to do), but also some background (what to
avoid).

Thus: yes, excellent idea. Go to it.

--
Anders Thulin Anders...@lejonet.se 013 - 23 55 32
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

Robert Hyatt

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
In article <4k31nt$e...@nala.devnet.lejonet.se>,
Anders Thulin <a...@nala.devnet.lejonet.se> wrote:
-->In article <4k0o22$5...@pelham.cis.uab.edu>,
-->Robert Hyatt <hy...@cis.uab.edu> wrote:
-->>
-->>It has been suggested, on several occasions, that I "volunteer" to
-->>undertake writing a book on the above subject. I've been giving this
-->>a lot of thought, and thought I'd query this group on the subject.
-->
--> As long as you won't call it "The Dum-dum's guide to computer
-->chess', 'Tricks of the computer chess masters', or 'Crafty Unleashed',
-->I don't think you'll have anything to worry about :-)
-->
-->>Topics might include:
-->>
-->>Move generation, using both bitmaps and the now common "X88"
-->>algorithm.
-->>[...]
-->
--> One thing I often find useful, but very rarely is presented
-->anywhere, is what to avoid and why. What didn't work? What might seem
-->to be a good idea, but turns out to be problematical? Those details
-->usually give a better grasp of the 'shape' of the problem/solution:
-->not only foreground (what to do), but also some background (what to
-->avoid).
-->
--> Thus: yes, excellent idea. Go to it.
-->
-->--
-->Anders Thulin Anders...@lejonet.se 013 - 23 55 32
-->Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden


One issue I probably didn't explain very well is that each "section"
would start off with some "nuts and bolts" that beginners would find
useful to get started, followed by the more sophisticated additions that
they will want to add as development proceeds.

Another suggestion that might make sense in a way, is to include a
CD-rom with a version of crafty on it. The book could then (at various
points) refer specifically to module names/line numbers for examples
of various things. Have to think about this, however, as I'm not sure
I want to "date" the book in such a way.

Andreas De Troy

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
news:4k35p0$6...@pelham.cis.uab.edu
hy...@cis.uab.edu (Robert Hyatt) wrote:

>Another suggestion that might make sense in a way, is to include a
>CD-rom with a version of crafty on it. The book could then (at various
>points) refer specifically to module names/line numbers for examples
>of various things. Have to think about this, however, as I'm not sure
>I want to "date" the book in such a way.
>

I don't think this is a good idea for your book. The Crafty-code looks
far too sophisticated to serve as a guide for understanding
how algorithms are implemented.

I think it would be a better idea if you gave examples in actual C-code,
but stripped down from all the housekeeping that must be done in a
particular program.

(Not that it would be a bad idea to include the Crafty-code on a CD-rom).


Jan Eric Larsson

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
>Robert Hyatt wrote:
>Another suggestion that might make sense in a way, is to include a
>CD-rom with a version of crafty on it. The book could then (at various
>points) refer specifically to module names/line numbers for examples
>of various things. Have to think about this, however, as I'm not sure
>I want to "date" the book in such a way.

Andreas De Troy writes:
>I don't think this is a good idea for your book. The Crafty-code looks
>far too sophisticated to serve as a guide for understanding
>how algorithms are implemented.

But I think it would be a good idea. Simplified code is exactly that,
simplified; and you won't produce a good chess program with simplified
code. The first thing that a beginner should know, before he/she sets
out to write a good chess program, is the size and complexity of the
problem. And if you take away the meat, the book's value is suddenly
much less. Then why not just go back to "Chess 4.5..." again?

mon...@utdallas.edu

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
Robert Hyatt (hy...@cis.uab.edu) wrote:

> It has been suggested, on several occasions, that I "volunteer" to

> undertake writing a book on the above subject. I've been giving this

> a lot of thought, and thought I'd query this group on the subject.

Your appended thoughts about an intro to each chapter on beginners' level
topics are welcome. Also, some history about development of
thought/skills in conceptualizing the problems, and consensus on
advantages and drawbacks of various approaches would be very interesting.

Your concerns about "dating" the work with sample code which would become
outdated seem to me unfounded: hopefully the state of the art *will*
continue to advance, but we, your public have curiosity *now*! <g> (Also,
consider "encapsulation" of the portion of the text which is most likely
to vary over time, and you have the lion's share of the
soon-to-be-classic "Second Edition" finished before you've sold the first
copy of the "First"!)

Good luck, and mark me down for a copy.

Don.
--
Don Montgomery mon...@utdallas.edu | "They'll be over soon, they said...
| Now they've lost themselves instead"

Andrey Kochetkov

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
That is best idea that you could produce for my joy. I am not top
programmer, but I think that every book should contain information
for beginners. That would be good to see many innovations which are
not tested yet.
Unfortunately I cannot provide any useful materials, but I can test
this book how it goes for reading by unexperienced programmers.
Anyway I will buy this book when it appears.

Andrew Kochetkov Computer Supervisor of Moscow association "Volja"
and...@glas.apc.org

Tom Kerrigan

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
The problem with including a Crafty CD isn't only dating but losing sight of the
goal. Even if you only include references, the book switches from "How to write a
chess computer program" to "Why I did x in Crafty". What would be appropriate, in
my opinion, is including two chapters at the end of the book outlining Crafty and
GNU Chess.

I remember my C64 days, when text adventure games were very popular. People would
buy "How to write an adventure game," copy the "FREE! Working adventure game!,"
and say, "Look! I wrote an adventure game!" If you include a working chess program
with a book, a shiny new nickel says there will be an explosion of clones, which
we already have in abundance anyway.

Cheers,
Tom

_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-

"It was a virgin forest, a place where the Hand of Man had never set
foot."

Chris Sterritt

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
Hello,

In the ongoing debate of a possible project :-),

In article <APC&63'0'30586767'9...@glas.apc.org>,
Andrey Kochetkov <and...@glas.apc.org> wrote:

>I am not top
>programmer, but I think that every book should contain information
>for beginners.

I'd like to put in a vote against this idea. I have (all?) or
at least several of the 'old' books on computer chess. These do a
fairly good job of presenting the basic ideas. I definitely agree
that most fall down in the area of providing specific implementation
details.

However, I really think that it would be something of a waste
for Mr. Hyatt to do yet another 'Beginner's book of Computer Chess',
at least at first. Do the 'Advanced Book', *including* a snapshot of
Crafty (in floppy/CD form or just the listing at the back). It's
what's really missing.

As an example, think of the classic 'Dragon Book' on compiler
design and implementation. Tough sledding in some ways, but it would
be three times as long and needlessly verbose if it tried to cover the
beginner's concepts of what a variable is, why you write a loop, etc.
What it does, it does very well.

--chris sterritt


Joe Stella

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to

hy...@cis.uab.edu (Robert Hyatt) wrote:


-->There are a few such books out, but they leave out almost
-->*all* of the important details and implementation specifics.


They sure do! I would love to see a book like this and I would
buy it right away.

I second Tom Kerrigan's idea about being careful that you don't
go above the heads of people who are just beginning. Maybe
it could be structured into a "beginners section" and an
"advanced section", where the beginners section just gives
enough information to get a complete chess program going (i.e.
minimax, alpha-beta, and simple evaluation heuristics), while the
advanced section talks about the things that can be added
to improve the program further.

Joe S.

MANOHARARAJAH VALAVAN

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
In article <4k3f45$r...@chaos.kulnet.kuleuven.ac.be>,

Andreas De Troy <Andreas...@ped.kuleuven.ac.be> wrote:
>news:4k35p0$6...@pelham.cis.uab.edu
>hy...@cis.uab.edu (Robert Hyatt) wrote:
>
>>Another suggestion that might make sense in a way, is to include a
>>CD-rom with a version of crafty on it. The book could then (at various
>>points) refer specifically to module names/line numbers for examples
>>of various things. Have to think about this, however, as I'm not sure
>>I want to "date" the book in such a way.
>>
>
>I don't think this is a good idea for your book. The Crafty-code looks
>far too sophisticated to serve as a guide for understanding
>how algorithms are implemented.

you have a point here...but Crafty is probably the best source code
I have seen for a chess program yet. GNUCHESS is a real pain to look at.
At least Crafty is well commented and relatively easier to understand and
probably plays much better than some programs out there.

>
>I think it would be a better idea if you gave examples in actual C-code,
>but stripped down from all the housekeeping that must be done in a
>particular program.
>
>(Not that it would be a bad idea to include the Crafty-code on a CD-rom).
>

Tom Kerrigan

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
A few people have posted about beginners' books on this thread. Where are these
books?? I haven't seen one to date. I had to learn this stuff by reading GNU Chess
source code on weekends and (much later) having conversations with Bruce Moreland.
I would have given an arm and a leg for a book, if only so I didn't annoy Bruce.

Cheers,
Tom

_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-

The reason computer chips are so small is computers don't eat much.

Anders Thulin

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
In article <4k35p0$6...@pelham.cis.uab.edu>,
Robert Hyatt <hy...@cis.uab.edu> wrote:

>Another suggestion that might make sense in a way, is to include a
>CD-rom with a version of crafty on it. The book could then (at various
>points) refer specifically to module names/line numbers for examples
>of various things. Have to think about this, however, as I'm not sure
>I want to "date" the book in such a way.

Excellent idea! That's just what's necessary to help the reader to
continue fairly easily 'past' the book -- by examining, experimenting,
trying out new ideas without having to do the whole thing from
scratch. It should be possible to just add pointers, comments to the
code without making the book difficult for people without the code.
And it would be possible to put very implementation-specific material
on the CD only.

I wouldn't worry about 'dating'. The TeXbook is a bit dated, but I
still refer to it for ideas. Minix is (I think?) old by now -- I
still read the book and the code. Xinu too. Randall & Russel's book
on their old Algol 60 compiler is another of those classics -- it
didn't have real source code, but the flowcharts were as close as you
could get. That book made compilers seem manageable to me. Nowadays
those books would naturally come with a CD.

I kept a copy of Chess 0.5 (? -- that Byte article with the chess
program in Pascal) for a very long time, reading and rereading the
code. I'm sure many others did.

--
Anders Thulin Anders...@lejonet.se 013 - 23 55 32

Robert Hyatt

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
In article <4k5a9v$l...@europa.frii.com>,

Tom Kerrigan <kerr...@frii.com> wrote:
>A few people have posted about beginners' books on this thread. Where are these
>books?? I haven't seen one to date. I had to learn this stuff by reading GNU Chess
>source code on weekends and (much later) having conversations with Bruce Moreland.
>I would have given an arm and a leg for a book, if only so I didn't annoy Bruce.
>
>Cheers,
>Tom
>

There are several:

1. Chess Skill in Man and Machine

2. How computers play chess. Levy/Newborn

3. Computer Chess. Newborn

4. Computer Chess. Dave Welch, published by Brown.

probably a couple of others, but these were "beginner type books" that
revealed too little.

5. Chess, Computers and Cognition. Probably too technical, in that this
has lots of details about three programs, Deep Thought, HiTech, and Cray
Blitz. The chapter on Cray Blitz reveals everything about the program, but
because it's only one chapter, it doesn't explain the basic things very well
at all.

Tom Kerrigan

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
Chess Skill in Man and Machine doesn't explain the basics, as I recall. I suppose
you could reverse engineer CHESS from the description but this would be very
difficult if you didn't know the basic design of a program. How Computers Play
Chess has screwed up more programs than helped them, in my experience. I think
this is because Levy doesn't actually play a part in the programming. I haven't
read the other books.

If I were to write a book, the first chapter would explain data setup. I would
describe simple, GNU-ish piece lists, linked piece lists, and bitboards. Then I
would list the functions in a chess program: in_check, generate, makemove,
takeback, sort, search, and evaluate. I would offer a description of each and
explain the data types usually associated with them (a generator stack, for
example). With this information, I think a programmer would have a lot of fun
writing the functions himself and end up with a decent program.

Cheers,
Tom

_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-

Q: How many DEC repairman does it take to fix a flat?
A: Five; four to hold the car up and one to swap tires.

Q: How long does it take?
A: It's indeterminate. It will depend upon how many flats they've
brought with them.

Q: What happens if you've got TWO flats?
A: They replace your generator.

Ed Parry

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
hy...@cis.uab.edu (Robert Hyatt) wrote:


>It has been suggested, on several occasions, that I "volunteer" to
>undertake writing a book on the above subject. I've been giving this
>a lot of thought, and thought I'd query this group on the subject.

> - snipith grandest here -

>Note that I'm not looking for firm customer offers here. :) just
>a "test the water" to see if most agree that such a thing would be

>useful. There are a few such books out, but they leave out almost


>*all* of the important details and implementation specifics.

>Bob

Hi Bob!

1) Is this a SERIOUS question? For a fellow in the FINDING ANSWERS
BEFORE THEY ARE ASKED BIZ (of sorts - re: Crafty), needing to ask is
not EVEN a quesiton. I think everyone that's even psuedo serious would
purchase such a critter, as well as be willing to make suggestions as
to what they would like to see included.

Myself? A GROUND UP chapter. As I've mentioned before, I have the move
gen down, I have a nice DOS based hires graphical crsr controlled
interface, and I've been cooking on n off on the thing since 1989.

Anyways, a beginning intro to the required ideas to get us started at
each stage of development, up thru the absolute latest breaking
goodies would be a FANTASIC book in my opinion.

Matter of fact, I'll order mine now.

Ep
Ed Parry
au...@lafn.org
edp...@primenet.com
EBBS HQ - 818-891-9350 - CA - Online chess, BASIC/ASM, Discussion


Joseph McCaughan contra

unread,
Apr 8, 1996, 3:00:00 AM4/8/96
to

Tom Kerrigan (kerr...@frii.com) wrote:
: I have found that the demand for a chess program "how to" book is amazing. Bob,

: Cheers,
: Tom

I have to agree with Tom here. I've been reading these
threads for several months. I have Levy/Newborn's book, (HCPC).
I've even written a Bourne-Shell driven chess player
under SVR2 on a 286 with 1MB RAM, (Guarrenteed 6 moves per hour!).

I still have no idea what these are:

1) null move.
2) quiecient(sp?) search.
3) hash tables.
4) other stuff...

Maybe you could just include a chapter for newbies.
I know it must be hard for those of you that have
achieved "chess-programming-nirvana" to come down and
help us floundering on the bottom... :)


Thanks Bob,

--Joe

--
Joe McCaughan /
jmc...@hposl61.cup.hp.com \ Two men looked out through prison bars,
Phone: (408) 447-7892 / One saw mud; the other, stars.
\

Peter Gillgasch

unread,
Apr 9, 1996, 3:00:00 AM4/9/96
to
In article <4k474o$5...@europa.frii.com>, kerr...@frii.com (Tom Kerrigan) writes:
|> The problem with including a Crafty CD isn't only dating but losing sight of the
|> goal. Even if you only include references, the book switches from "How to write a
|> chess computer program" to "Why I did x in Crafty". What would be appropriate, in
|> my opinion, is including two chapters at the end of the book outlining Crafty and
|> GNU Chess.

I agree with that. Bob is the best person to discuss different approaches to
computer chess program since he is "in business" since some 20 years. I'd suggest
to discuss the old CB design (which was 0x88 I think?), the Crafty design starting
with a chapter "What I really hated about the old CB" and (I know that this one
is hard to swallow :) the GNU chess design (call that chapter "The program that
lead people astray" ;)

|> I remember my C64 days, when text adventure games were very popular. People would
|> buy "How to write an adventure game," copy the "FREE! Working adventure game!,"
|> and say, "Look! I wrote an adventure game!" If you include a working chess program
|> with a book, a shiny new nickel says there will be an explosion of clones, which
|> we already have in abundance anyway.

I agree with that one as well. DON'T tease the people to build
a clone by providing the whole source. Let them think on their
own, possibly they are better than we are.

-- Peter

------------------------------------------------------------
Peter W. Gillgasch
Klosterweg 28/I-113 email gil...@ira.uka.de
76131 Karlsruhe/Germany Phone ++49/(0)721/6904255

Peter Gillgasch

unread,
Apr 9, 1996, 3:00:00 AM4/9/96
to
In article <4k6enj$7...@europa.frii.com>, kerr...@frii.com (Tom Kerrigan) writes:
|> Chess Skill in Man and Machine doesn't explain the basics, as I recall. I suppose
|> you could reverse engineer CHESS from the description but this would be very
|> difficult if you didn't know the basic design of a program. How Computers Play
|> Chess has screwed up more programs than helped them, in my experience.

Hum. I read this *after* writing my first program... ;)

|> I think
|> this is because Levy doesn't actually play a part in the programming. I haven't
|> read the other books.

Let's be fair to David. NO program that was actually *written* by a chess master
was top notch (before you cry "foul" I think Berliner is mainly a designer, not
an implementor). I hope that this changes some time... Read Botvinniks books (may
he rest in peace) THEN you will understand what "screwed up" books by chess masters
look like... Actually Botvinnik's book was the only book in our local library as I
was a kid that bought his first computer (VIC-20 :) and after I read it I thought
"well, let's forget about that project".

I have read "Chess Skill in Man and Machine", the ACC books, David's books,
"Computers, Chess and Cognition" and none of those is really a good start for
a beginner. The best I ever saw was either source code or special hardware
descriptions. If Bob is really going to write that book he would do a tremendous
favour to all chess programmers and possibly he would spoil a couple of hundred
young people for the rest of their lives :)

|> If I were to write a book, the first chapter would explain data setup. I would
|> describe simple, GNU-ish piece lists, linked piece lists, and bitboards. Then I
|> would list the functions in a chess program: in_check, generate, makemove,
|> takeback, sort, search, and evaluate. I would offer a description of each and
|> explain the data types usually associated with them (a generator stack, for
|> example). With this information, I think a programmer would have a lot of fun
|> writing the functions himself and end up with a decent program.

Yes. If they cannot make it up from good descriptions they are doomed anyway :)

|> Tom Kerrigan kerr...@frii.com O-
|>
|> Q: How many DEC repairman does it take to fix a flat?
|> A: Five; four to hold the car up and one to swap tires.
|>
|> Q: How long does it take?
|> A: It's indeterminate. It will depend upon how many flats they've
|> brought with them.
|>
|> Q: What happens if you've got TWO flats?
|> A: They replace your generator.

Q: How many DEC managers are needed to get you an Alpha in Hong Kong?

A: Definitively less than 3 and a half. 1 in Europe that tries to get you
one, 1 in Europe that puts the other one down, 1 that smiles at you in
Hong Kong giving you his card offering "all the help that is possible"
expressing his deepest gratitude that you run on an Alpha that you don't
have, 1/2 that smiles at the generosity of his boss, a smart friend (TM) that
keeps you from kicking them and finally the wonderful Maxi Hui to get you
one from the local physics department saving DarkThought from being simulated
by hand :)

Martin Borriss

unread,
Apr 9, 1996, 3:00:00 AM4/9/96
to

To solve the problem of the 'book to be' being useful to both beginners and
experienced programmers you might consider to split everything into a discussion
of concepts and description of implementation details.
This is like the approach Rich Stephens took in his TCP/IP books.

Anyway, such a book is of great need for people wanting to write a program but
have to learn it the hard way and might eventually drop out of those projects
because of limited time and success.

Thanks to some of the best chess programmers on the net I learned many of the
things which the book might teach in a shorter time ;)

Martin

--
Martin....@inf.tu-dresden.de

Martin Borriss

unread,
Apr 9, 1996, 3:00:00 AM4/9/96
to

Hmm. Just want to mention that even in the former GDR chess computer books have
been published. Since Tom reads German very well ;) - it's titled
"Computerschach und Schachcomputer" by Posthoff and Reinemann.
GM Knaak played a bit with a weak program mentioned in the book.
Unfortunately, it is not so hot if you want to build a program from this,
no readable source code is given.

Martin

--
Martin....@inf.tu-dresden.de

Robert Hyatt

unread,
Apr 9, 1996, 3:00:00 AM4/9/96
to
In article <4kce5h$m...@nz12.rz.uni-karlsruhe.de>,
Peter Gillgasch <gil...@ira.uka.de> wrote:
-->In article <4k474o$5...@europa.frii.com>, kerr...@frii.com (Tom Kerrigan) writes:
-->|> The problem with including a Crafty CD isn't only dating but losing sight of the
-->|> goal. Even if you only include references, the book switches from "How to write a
-->|> chess computer program" to "Why I did x in Crafty". What would be appropriate, in
-->|> my opinion, is including two chapters at the end of the book outlining Crafty and
-->|> GNU Chess.
-->
-->I agree with that. Bob is the best person to discuss different approaches to
-->computer chess program since he is "in business" since some 20 years. I'd suggest
-->to discuss the old CB design (which was 0x88 I think?),

No, we canned that in CB very early on, because it was much faster to do a vector
load of all squares on a particular ray, then detect a piece like "99" as the
edge of the board, because it fit the architecture of the cray better. I don't
think we used X88 after about 1981 or so when Harry started looking at the
vectorized move generator we developed.


--> the Crafty design starting
-->with a chapter "What I really hated about the old CB" and (I know that this one
-->is hard to swallow :) the GNU chess design (call that chapter "The program that
-->lead people astray" ;)
-->
-->|> I remember my C64 days, when text adventure games were very popular. People would
-->|> buy "How to write an adventure game," copy the "FREE! Working adventure game!,"
-->|> and say, "Look! I wrote an adventure game!" If you include a working chess program
-->|> with a book, a shiny new nickel says there will be an explosion of clones, which
-->|> we already have in abundance anyway.
-->
-->I agree with that one as well. DON'T tease the people to build
-->a clone by providing the whole source. Let them think on their
-->own, possibly they are better than we are.
-->
-->-- Peter
-->

Tom Kerrigan

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to
Yes, Martin, quite right. I had totally forgotten about German books. Thanks. :)

I read parts of a few German books on chess programming in Paderborn, and I can't
find fault in any of them. I regret that I can't refer people to them because of
the language barrier. I wonder how much the books impact the popularity of the
sport? In any case, if one were to write a book on the subject, I would think it
very helpful if he looked at these examples first.

Cheers,
Tom

P.S. It's a shame these books were the only things in German that I totally
understood that week, eh? :D

_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-

Life would be so much easier if we could just look at the source code.

Loh Weng Keong Calvin

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to
Andreas De Troy (Andreas...@ped.kuleuven.ac.be) wrote:
: news:4k35p0$6...@pelham.cis.uab.edu
: hy...@cis.uab.edu (Robert Hyatt) wrote:

: >Another suggestion that might make sense in a way, is to include a
: >CD-rom with a version of crafty on it. The book could then (at various
: >points) refer specifically to module names/line numbers for examples
: >of various things. Have to think about this, however, as I'm not sure
: >I want to "date" the book in such a way.

: >

: I think it would be a better idea if you gave examples in actual C-code,

: but stripped down from all the housekeeping that must be done in a
: particular program.

: (Not that it would be a bad idea to include the Crafty-code on a CD-rom).

Please! Not on cd-rom. 3 1/2" diskettes would be best for those who do
not have cd-rom drivers.

--
Calvin Loh

Steven J. Edwards

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to

I would recommend getting a CD-ROM drive. Earlier today I purchased a
6x Mitsumi CD-ROM IDE drive new for US$149 including software,
cabling, and mounting hardware. A 4x version was available for only
US$89.

-- Steven (s...@mv.mv.com)

GivenRandy

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
I agree about getting a CD-ROM - it is a "must" today if you are serious
about any computer work. Trying to release such information on diskette
is not practical (cost and size considerations). Of course, this
increases the cost slightly, but should be worth it.

Randy Given <Given...@aol.com>

Vincent Diepeveen

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
>...

>Let's be fair to David. NO program that was actually *written*
>by a chess master

It seems so. Tactical programs seem to be well enough, but as again
appeared in Aegon, certain simplistic heuristics humans use, and that
CAN be implemented to a certain level, even the 'greatest' program suffer
from.

>was top notch (before you cry "foul" I think Berliner is mainly a designer,
>not
>an implementor). I hope that this changes some time... Read Botvinniks books
> (may he rest in peace) THEN you will understand what
> "screwed up" books by chess masters
>look like... Actually Botvinnik's book was the only book in our local
>library as I
>was a kid that bought his first computer (VIC-20 :)
>and after I read it I thought
>"well, let's forget about that project".

>I have read "Chess Skill in Man and Machine", the ACC books, David's books,
>"Computers, Chess and Cognition" and none of those is really a good start for
>a beginner. The best I ever saw was either source code or special hardware

I also have a lot of these books.

Source code, Robert Hyatt, and emailing with computerchessprogrammers.
No book tells something these guys didn't already tell you.


>|> If I were to write a book, the first chapter would explain data setup. I would
>|> describe simple, GNU-ish piece lists, linked piece lists, and bitboards.

I'd begin to tell how to speed up a program.
It seems that speed is very important.

Yesterday in Aegon my program played a lot of terrible moves. It appeared that
certain knowledge was not in the program. It would however found a better
move in 1 of the cases anyway if it searched 11 ply.
It actually searched 9... ...at a P166.

--
+--------------------------------------+
|| email : vdie...@cs.ruu.nl ||
|| Vincent Diepeveen ||
+======================================+

Jean-Christophe Weill

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
Joseph McCaughan contra wrote:
>
> Tom Kerrigan (kerr...@frii.com) wrote:
> : I have found that the demand for a chess program "how to" book is amazing. Bob,
> : you list a number of topics I would consider relatively advanced. I think a simple
> : tutorial would have more effect, and if the reader wants more information he can
> : find it in an ICCA journal (or somewhere). Anyway, if you ever decide to write
> : something and need some help, feel free to ask me to write a chapter or two.
> : Probably not about the evaluation function, but you get the idea. :)
>
> : Cheers,
> : Tom
>
>
> I still have no idea what these are:
>
> 1) null move.
> 2) quiecient(sp?) search.
> 3) hash tables.
> 4) other stuff...
>


At least for a start on this advanced subject for those you can
understand french, they can look at my PHD thesis under

http://www.neci.nj.nec.com/homepages/jcw

I know of several non frenc computer chess programmers that was able
with little work to understand the heuristics Chapter of this thesis.

BTW, I plan to release it in English when I'll find enough time for
the translation.


--
From: Jean-Christophe Weill
NEC Research Institute (Room 2f07) 4 Independence Way Princeton NJ 08540
USA
Phone: (609) 951-2792 Email: j...@research.nj.nec.com
Fax: (609) 951-2482 ("for J.C. Weill")

Alan Tomalty

unread,
Apr 20, 1996, 3:00:00 AM4/20/96
to
> EBBS HQ - 818-891-9350 - CA - Online chess, BASIC/ASM, DiscussionI will order a copy also. Everybody has waiting for years for Robert
Hyatt to write a book on computer chess. If the book starts from scratch
and gives you enough detail to actually produce a working chess
program, it will be a big seller. The Spracklen book left out key
details at the introductory stages. Komputer Korner

Robert Hyatt

unread,
Apr 21, 1996, 3:00:00 AM4/21/96
to
In article <31794F...@iosphere.net>,
Alan Tomalty <kor...@iosphere.net> wrote:
-->Ed Parry wrote:
-->>
-->> hy...@cis.uab.edu (Robert Hyatt) wrote:
-->>
-->> >It has been suggested, on several occasions, that I "volunteer" to
-->> >undertake writing a book on the above subject. I've been giving this
-->> >a lot of thought, and thought I'd query this group on the subject.
-->>
-->> > - snipith grandest here -
-->>
-->> >Note that I'm not looking for firm customer offers here. :) just
-->> >a "test the water" to see if most agree that such a thing would be
-->> >useful. There are a few such books out, but they leave out almost
-->> >*all* of the important details and implementation specifics.
-->>
-->> >Bob
-->>
-->> Hi Bob!
-->>
-->> 1) Is this a SERIOUS question? For a fellow in the FINDING ANSWERS
-->> BEFORE THEY ARE ASKED BIZ (of sorts - re: Crafty), needing to ask is
-->> not EVEN a quesiton. I think everyone that's even psuedo serious would
-->> purchase such a critter, as well as be willing to make suggestions as
-->> to what they would like to see included.
-->>
-->> Myself? A GROUND UP chapter. As I've mentioned before, I have the move
-->> gen down, I have a nice DOS based hires graphical crsr controlled
-->> interface, and I've been cooking on n off on the thing since 1989.
-->>
-->> Anyways, a beginning intro to the required ideas to get us started at
-->> each stage of development, up thru the absolute latest breaking
-->> goodies would be a FANTASIC book in my opinion.
-->>
-->> Matter of fact, I'll order mine now.
-->>
-->> Ep
-->> Ed Parry
-->> au...@lafn.org
-->> edp...@primenet.com
-->> EBBS HQ - 818-891-9350 - CA - Online chess, BASIC/ASM, DiscussionI will order a copy also. Everybody has waiting for years for Robert
-->Hyatt to write a book on computer chess. If the book starts from scratch
--> and gives you enough detail to actually produce a working chess
-->program, it will be a big seller. The Spracklen book left out key
-->details at the introductory stages. Komputer Korner


My synopsis is that while there are a fair number of computer chess books
around, they either prattle on endlessly about the simple things, and omit
the parts that make the program really function (hash tables is but one big
example) or else they get very specific about a program, but then overlook
the important simple things that make a program work in the first place. I'm
afraid this might be a relatively "pricey" book that I'm working on because
it's going to be pretty big, as I want to cover all the basics and the important
advanced things like hashing, null-move, search, etc. An example: I'll bet
I can't count the number of times I've been asked "OK, I understand the
negamax search, but I can't figure out how to get the best move or even
the best path. How do you do it?" I'd like to start off with the simple
negamax, but insert hash lookups, repetition checks, PV bookkeeping, and
so forth in successive versions so that by the end of the "search" chapter,
you'll have a complete search psuedo-code to work with. It's amazing just
how important details get left out. For those of us doing this for years,
the omissions are great because I know where the missing things go, and I
like the more concise psuedo-code their omission produces. But for someone
just getting into this, it appears that the frustration of playing "fill in
the blank as an exercise to the reader" is significant.

CWilli1596

unread,
Apr 21, 1996, 3:00:00 AM4/21/96
to
>I'm afraid this might be a relatively "pricey" book that I'm working on
because
>it's going to be pretty big, as I want to cover all the basics and the
important
>advanced things like hashing, null-move, search, etc.

I doubt it will be any more "pricey" than what I shell out for textbooks
every month.:) And it might be more useful. When I graduate and have
some time on my hands, I'd like to try my hand at writing one of these
things. It must be a great feeling when one loses for the first time to
his or her own chess program!

Chuck

P.S. A suggestion: Please include a glossary.

Steven J. Edwards

unread,
Apr 22, 1996, 3:00:00 AM4/22/96
to
hy...@cis.uab.edu (Robert Hyatt) writes:

>My synopsis is that while there are a fair number of computer chess books
>around, they either prattle on endlessly about the simple things, and omit
>the parts that make the program really function (hash tables is but one big
>example) or else they get very specific about a program, but then overlook

>the important simple things that make a program work in the first place. I'm


>afraid this might be a relatively "pricey" book that I'm working on because
>it's going to be pretty big, as I want to cover all the basics and the important
>advanced things like hashing, null-move, search, etc.

Some more examples:

1) Test suites, benchmarking, and program strength evaluation: I have
never seen a book that covers this in any detail. New developers need
to know the practive and pitfalls of using test suites. They also
should know how to either get them or create them in the first place.
How many people have typed in _Win at Chess_? I did, and it was
pretty mind numbing. Note that I do not suggest that developers
simply download files; rather, the original books themselves are
necessary for the variations, annotations, and analysis.

2) Opening libraries: Again, I have never seen an article that
describes automated book construction and it's been many years since I
saw a detailed example of some of the possible book representations.

3) Endgame databases: While numerous articles have appeared, there has
been no in-depth treatment in any book that I've seen. There are
plenty of issues here including construction, use in search, and
sources of pre-built databases.

4) Notation issues for moves, positions, games, and interprogram
communication. There's no comprehensive treatment of this in print.
Yet this is one of the basic tasks and is much more easily handled at
the start of program design instead of as an afterthought.

5) Coding for portability: neophyte programmers often forget the
importance of this and so write code that is often unnecessarily
platform dependent. Many of the pioneering programs are no longer
available to us because the original software and hardware has gone
without successors.

6) Real time interfacing to other programs including database
programs: items best not handled as afterthoughts.

In addition to chapters for each of the above, I would add a chapter
at the end of the book entitled something like:

"Provocative ideas in need of research and development"

And the chapter would be loaded with suggestions on topics that sound
promising, but of which no one has yet gotten to work in a production
program. Machine learning techniques borrowed from general AI
research could cover a third of the chapter. Other topics might
include opponent modelling, search trees as linguistic structures,
analysis in the pattern domain, and search as theorem proving.

Of course, this last suggestion above may induce the reader to spend
lots of time on some topics with no guarantee of any productive
results. In others, just like the rest of us. If successful, the
effort may make a big contribution to the Art. If not, well at least
the reader will have a better appreciation of what others have done in
the past.

-- Steven (s...@mv.mv.com)

J-P Fendrich

unread,
Apr 22, 1996, 3:00:00 AM4/22/96
to
Robert Hyatt wrote:
>
> In article <31794F...@iosphere.net>,
> Alan Tomalty <kor...@iosphere.net> wrote:

<..lots of snipping...>
-->Everybody has waiting for years for Robert


> -->Hyatt to write a book on computer chess. If the book starts from scratch
> -->and gives you enough detail to actually produce a working chess
> -->program, it will be a big seller. The Spracklen book left out key
> -->details at the introductory stages. Komputer Korner
>

> My synopsis is that while there are a fair number of computer chess books
> around, they either prattle on endlessly about the simple things, and omit
> the parts that make the program really function (hash tables is but one big
> example) or else they get very specific about a program, but then overlook
> the important simple things that make a program work in the first place. I'm
> afraid this might be a relatively "pricey" book that I'm working on because
> it's going to be pretty big, as I want to cover all the basics and the important

> advanced things like hashing, null-move, search, etc. An example: I'll bet
> I can't count the number of times I've been asked "OK, I understand the
> negamax search, but I can't figure out how to get the best move or even
> the best path. How do you do it?" I'd like to start off with the simple
> negamax, but insert hash lookups, repetition checks, PV bookkeeping, and
> so forth in successive versions so that by the end of the "search" chapter,
> you'll have a complete search psuedo-code to work with. It's amazing just
> how important details get left out. For those of us doing this for years,
> the omissions are great because I know where the missing things go, and I
> like the more concise psuedo-code their omission produces. But for someone
> just getting into this, it appears that the frustration of playing "fill in
> the blank as an exercise to the reader" is significant.
>
> --
> 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


Hello Bob,

I'm really waiting for your book to come, but pleaase don't make it
a general programming tutorial. Some subject sometimes is referred to as
basic chess programming techniques, but really are not.
e.g. Recursive programming.

There are lots of topics to cover, as you mention, even without theese basics.

--
JP Fendrich, Volvo Data, Gothenburg, Sweden

Robert Hyatt

unread,
Apr 23, 1996, 3:00:00 AM4/23/96
to
In article <4lk49m$e...@airnews.iadfw.net>,
Robert Canright <canr...@airmail.net> wrote:
-->Jean-Christophe Weill <j...@research.nj.nec.com> wrote:
-->
-->>Joseph McCaughan contra wrote:
-->>>
-->>> Tom Kerrigan (kerr...@frii.com) wrote:
-->>> : I have found that the demand for a chess program "how to" book is amazing. Bob,
-->>> : you list a number of topics I would consider relatively advanced. I think a simple
-->>> : tutorial would have more effect, and if the reader wants more information he can
-->>> : find it in an ICCA journal (or somewhere). Anyway, if you ever decide to write
-->>> : something and need some help, feel free to ask me to write a chapter or two.
-->>> : Probably not about the evaluation function, but you get the idea. :)
-->>>
-->>> : Cheers,
-->>> : Tom
-->
-->What is the ICCA?
-->
-->Rob Canright
-->


It's the "International Computer Chess Association" formed in 1977 at the
Toronto world championship if my memory serves. It publishes a quarterly
journal of computer chess research papers, organizes the World Computer
Chess Championship every three years, and the World MicroComputer Chess
Championship every year.

Robert Canright

unread,
Apr 24, 1996, 3:00:00 AM4/24/96
to
Jean-Christophe Weill <j...@research.nj.nec.com> wrote:

>Joseph McCaughan contra wrote:
>>
>> Tom Kerrigan (kerr...@frii.com) wrote:

>> : I have found that the demand for a chess program "how to" book is amazing. Bob,

>> : you list a number of topics I would consider relatively advanced. I think a simple

>> : tutorial would have more effect, and if the reader wants more information he can

>> : find it in an ICCA journal (or somewhere). Anyway, if you ever decide to write

>> : something and need some help, feel free to ask me to write a chapter or two.

>> : Probably not about the evaluation function, but you get the idea. :)
>>

>> : Cheers,
>> : Tom

What is the ICCA?

Rob Canright


Tom Kerrigan

unread,
Apr 24, 1996, 3:00:00 AM4/24/96
to
It seems to me a discussion of recursion is mandatory for such a book, if only
because there are dozens of posts to this group about alpha-beta pseudocode.
Granted, recursion is a simple concept (a function calls itself; this is not hard
to understand) but if the book just says "write a recursive search function" the
readership drops by 99%.

Cheers,
Tom

_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-

Heavy, adj.:
Seduced by the chocolate side of the force.

Dennis Breuker

unread,
Apr 24, 1996, 3:00:00 AM4/24/96
to

hy...@cis.uab.edu (Robert Hyatt) wrote:

>In article <4lk49m$e...@airnews.iadfw.net>,
>Robert Canright <canr...@airmail.net> wrote:
>-->What is the ICCA?
>-->
>-->Rob Canright
>-->

>It's the "International Computer Chess Association" formed in 1977 at the
>Toronto world championship if my memory serves. It publishes a quarterly
>journal of computer chess research papers, organizes the World Computer
>Chess Championship every three years, and the World MicroComputer Chess
>Championship every year.

Check this one out:
http://www.cs.rulimburg.nl/icca/

Dennis.


Robert Hyatt

unread,
Apr 24, 1996, 3:00:00 AM4/24/96
to
In article <4lkmaj$9...@europa.frii.com>,
Tom Kerrigan <kerr...@frii.com> wrote:
-->It seems to me a discussion of recursion is mandatory for such a book, if only
-->because there are dozens of posts to this group about alpha-beta pseudocode.
-->Granted, recursion is a simple concept (a function calls itself; this is not hard
-->to understand) but if the book just says "write a recursive search function" the
-->readership drops by 99%.

-->
-->Cheers,
-->Tom
-->
-->_______________________________________________________________________________
-->Tom Kerrigan kerr...@frii.com O-
-->
-->Heavy, adj.:
--> Seduced by the chocolate side of the force.


I'm planning on a mid-road approach. This book can't possibly cover
recursion as a topic itself, because that's a classic programming issue
that goes far beyond chess, into the realm of local data variable allocation,
stacks, etc. It's also covered in practically every programming language
book and course that's offered. It'd be too easy to turn this into a
programming trick book, but there's plenty of info on board representations,
and other topics that will make this a "biggee" already...

However, I plan on giving several psuedo-code search functions, each with
more detail on how to back up PV's, how to catch repetitions, do hash
lookups, where to store killer moves, increment history counts, etc...

J-P Fendrich

unread,
Apr 24, 1996, 3:00:00 AM4/24/96
to
Robert Hyatt wrote:

>
> I'm planning on a mid-road approach. This book can't possibly cover
> recursion as a topic itself, because that's a classic programming issue
> that goes far beyond chess, into the realm of local data variable allocation,
> stacks, etc. It's also covered in practically every programming language
> book and course that's offered. It'd be too easy to turn this into a
> programming trick book, but there's plenty of info on board representations,
> and other topics that will make this a "biggee" already...
>
> However, I plan on giving several psuedo-code search functions, each with
> more detail on how to back up PV's, how to catch repetitions, do hash
> lookups, where to store killer moves, increment history counts, etc...
>
> --
> 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

I think most chess programmers would like that approach.

One intresting topic, not well covered by any book as far as I know, is
testing and fault finding. IMHO to test a chess program is far from business as
usual. A question like "why is that clumsy clot making this strange move?" may well
be hidden deep in the tree. Evaluation problem? Bug in the hash table code, alfa/beta code
or what? A combination of errors?

Well, when I ask myself the same question I never find the answear...
And maybe it's easier to correct the program? :)

Steven J. Edwards

unread,
Apr 25, 1996, 3:00:00 AM4/25/96
to
hy...@cis.uab.edu (Robert Hyatt) writes:

>I'm planning on a mid-road approach. This book can't possibly cover
>recursion as a topic itself, because that's a classic programming issue
>that goes far beyond chess, into the realm of local data variable allocation,
>stacks, etc. It's also covered in practically every programming language
>book and course that's offered. It'd be too easy to turn this into a
>programming trick book, but there's plenty of info on board representations,
>and other topics that will make this a "biggee" already...

Better to be too big than too small.

But I agree that it is probably impossible to produce a comprehensive
middle-road work on computer chess in a single volume. Still, I would
vote for at least a mention of some of the more esoteric or obscure
topics even if they don't receive a detailed explanation. Some of
these resist a general treatment because of their dependence on
platform specifics, yet still play an important role in a program.

One example of the above is search termination protocol including both
user interrupts and ponder search interrupt/transformation. There are
a number of ways of handling this (threads, multiple processes, even
the dreaded setjmp()/longjmp() routines), and if the author knows
about the problem then he/she has a better chance of getting it right
the first time.

Another area concerns the practice of defensive programming specific
to chess. It is probable that an author will spend the largest amount
of his/her time in fromt of the machine performing debugging tasks.
Therefore, it is prudent to cover some of the tricks that make this
easier. These include: support for deterministic search in order to
have repeatability; support for search node ordinal tags and triggers
in order to identify and trace specific problems in the search;
support for a variety of run time enabled diagnostic trace flags;
support for output dribble files; support for command file input;
support for conditional compilation of sanity checks in strategic
routines (ExecuteMove(), TranspositionStore(), etc.).

-- Steven (s...@mv.mv.com)


Robert Hyatt

unread,
Apr 25, 1996, 3:00:00 AM4/25/96
to

In article <DqFF3...@mv.mv.com>, Steven J. Edwards <s...@mv.mv.com> wrote:
-->hy...@cis.uab.edu (Robert Hyatt) writes:
-->
-->>I'm planning on a mid-road approach. This book can't possibly cover
-->>recursion as a topic itself, because that's a classic programming issue
-->>that goes far beyond chess, into the realm of local data variable allocation,
-->>stacks, etc. It's also covered in practically every programming language
-->>book and course that's offered. It'd be too easy to turn this into a
-->>programming trick book, but there's plenty of info on board representations,
-->>and other topics that will make this a "biggee" already...
-->
-->Better to be too big than too small.
-->
-->But I agree that it is probably impossible to produce a comprehensive
-->middle-road work on computer chess in a single volume. Still, I would
-->vote for at least a mention of some of the more esoteric or obscure
-->topics even if they don't receive a detailed explanation. Some of
-->these resist a general treatment because of their dependence on
-->platform specifics, yet still play an important role in a program.
-->
-->One example of the above is search termination protocol including both
-->user interrupts and ponder search interrupt/transformation. There are
-->a number of ways of handling this (threads, multiple processes, even
-->the dreaded setjmp()/longjmp() routines), and if the author knows
-->about the problem then he/she has a better chance of getting it right
-->the first time.
-->
-->Another area concerns the practice of defensive programming specific
-->to chess. It is probable that an author will spend the largest amount
-->of his/her time in fromt of the machine performing debugging tasks.
-->Therefore, it is prudent to cover some of the tricks that make this
-->easier. These include: support for deterministic search in order to
-->have repeatability; support for search node ordinal tags and triggers
-->in order to identify and trace specific problems in the search;
-->support for a variety of run time enabled diagnostic trace flags;
-->support for output dribble files; support for command file input;
-->support for conditional compilation of sanity checks in strategic
-->routines (ExecuteMove(), TranspositionStore(), etc.).
-->
-->-- Steven (s...@mv.mv.com)
-->


My intent is to not omit any chess-specific topic intentionally, but to
avoid non-chess programming tricks. I'll discuss efficiency issues at
the right points, but don't plan on tons of optimization stuff that's
normally taught in programming classes or else in the even better school
of "experience". :)

As I teach software engineering (among other things like architecture
and so forth) I certainly plan on addressing software engineering issues
at appropriate points, include many of the topics you mention like
how to debug, how to "plan" for future debugging, etc.

Robert Hyatt

unread,
Apr 28, 1996, 3:00:00 AM4/28/96
to

In article <83071192...@cpsoft.demon.co.uk>,
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
-->canr...@airmail.net (Robert Canright) wrote:
-->>

-->> Jean-Christophe Weill <j...@research.nj.nec.com> wrote:
-->>
-->> >Joseph McCaughan contra wrote:
-->> >>
-->> >> Tom Kerrigan (kerr...@frii.com) wrote:
-->> >> : I have found that the demand for a chess program "how to" book is amazing. Bob,
-->> >> : you list a number of topics I would consider relatively advanced. I think a simple
-->> >> : tutorial would have more effect, and if the reader wants more information he can
-->> >> : find it in an ICCA journal (or somewhere). Anyway, if you ever decide to write
-->> >> : something and need some help, feel free to ask me to write a chapter or two.
-->> >> : Probably not about the evaluation function, but you get the idea. :)

-->> >>
-->> >> : Cheers,
-->> >> : Tom
-->>
-->> What is the ICCA?
-->>
-->> Rob Canright
-->>
-->
-->It is computer chess's very own mafia.
-->
-->Chris Whittington
-->


As I've said before, the ICCA's a long way from being perfect. However,
they are also a long way above the next-best computer chess organization,
because there *is* no second-best computer chess organization.

Also, the term "mafia" is silly, because that stands for "organized
crime". I've never heard the ICCA accused of anything dishonest at
all. Maybe at times they have caviar tastes and a peanut-butter
budget, and maybe they spend more money (at times) on guests and
ICCA higher-ups than is spent on participants, but until you are on
any type of conference organizing committee, you can't throw stones,
because *every* conference I've seen does the same thing. Doesn't make
it right of course, but it doesn't make ICCA unique either.

Got any other sorts of journals you'd recommend reading for aspiring
computer chess programmers, besides the ICCA journal? Me neither...

Uterkorner

unread,
May 1, 1996, 3:00:00 AM5/1/96
to

Actually the ICCA is the computer chess equivalent of the Nobel commitee
that awards the Nobel prizes. Obviously, Mr. Whittington has had a bad
experience with them. Komputer Korner

Chris Whittington

unread,
May 5, 1996, 3:00:00 AM5/5/96
to

You said it !

But correction over prizes. The World Micro Championships for which
the ICCA collects a minimum of $20,000 sponsorship + $4000 for each
hardware machine entered + $1000 for each 'commercial' program entered
pays no prizes at all.

Where the money goes continues to be a mystery, since ICCA don't
appear to publish accounts of tournament income.

They used to publish accounts of membership dues etc. but these
never appeared to include the quite lucrative (in comparison)
income from tourneys; and these accounts are no longer given in the ICCA
journal.


Chris Whittington


Jonathan Schaeffer

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

Chris Whittington <chr...@cpsoft.demon.co.uk> writes:
>But correction over prizes. The World Micro Championships for which
>the ICCA collects a minimum of $20,000 sponsorship + $4000 for each
>hardware machine entered + $1000 for each 'commercial' program entered
>pays no prizes at all.
>
>Where the money goes continues to be a mystery, since ICCA don't
>appear to publish accounts of tournament income.
>
>They used to publish accounts of membership dues etc. but these
>never appeared to include the quite lucrative (in comparison)
>income from tourneys; and these accounts are no longer given in the ICCA
>journal.

I'm sorry but you are wrong. As former treasurer, all you have to do is
look at my annual reports in the ICCA Journal. They include all the
tournament income. From the statements, you can see that most of the money
goes to subsidize the ICCA Journal; membership fees do not cover the cost
of producing the publication.

Since 1993, Don Beal has been Treasurer. His statements also appear in the
Journal.

Your comments are unfair, insinuating that the ICCA is doing something
underhanded. Check your facts before you start making accusations.

Chris Whittington

unread,
May 6, 1996, 3:00:00 AM5/6/96
to

jona...@cs.ualberta.ca (Jonathan Schaeffer) wrote:
>
> Chris Whittington <chr...@cpsoft.demon.co.uk> writes:
> >But correction over prizes. The World Micro Championships for which
> >the ICCA collects a minimum of $20,000 sponsorship + $4000 for each
> >hardware machine entered + $1000 for each 'commercial' program entered
> >pays no prizes at all.
> >
> >Where the money goes continues to be a mystery, since ICCA don't
> >appear to publish accounts of tournament income.
> >
> >They used to publish accounts of membership dues etc. but these
> >never appeared to include the quite lucrative (in comparison)
> >income from tourneys; and these accounts are no longer given in the ICCA
> >journal.
>
> I'm sorry but you are wrong. As former treasurer, all you have to do is
> look at my annual reports in the ICCA Journal. They include all the
> tournament income.

The journal has conventionally given the financial statement in March.
This year (1996) there has been no statement.


> From the statements, you can see that most of the money
> goes to subsidize the ICCA Journal; membership fees do not cover the cost
> of producing the publication.


That's exactly where I've been looking. And yes, these accounts do
show an item for tournament income. But the item is for income *after*
expenses. What the expenses are is not shown. What the total take
from a tournament is is not shown. David Levy informs me that the
sponsorship requirement is $20,000, add to that manufacturor's fee
and commercial fees and you can arrive at what ? $30,000, $40,000 ?

The income figures plucked from 1992, 1994, 1995 are $3919, $14,500,
$0. (I don't have anything for 1993).

Without the total take figures, it is not possible to estimate the
expenses but these seem to be not trivial.

Each treasurers report usually makes a comment about a relatively
tight financial situation, and published detailed expense listings
of secretarial help, bank interest, sales income, subscription
income and so on.

But the sums involved in the above might well be dwarfed by the
tournament expenses.

Why does the ICCA not detail the full tournament income and the
expenses paid out for the tournaments in a similar way to its accounts
for the journal ?


>
> Since 1993, Don Beal has been Treasurer. His statements also appear in the
> Journal.
>
> Your comments are unfair, insinuating that the ICCA is doing something
> underhanded. Check your facts before you start making accusations.

I think I said your accounts were a mystery to me. Why should you
consider this an accusation ? They are a mystery.

Facts were checked.
Please tell me if my figures of $20,000 + $4000 x A + $1000 x B
are wrong.
Please tell me when ICCA publishes its report, I had assumed yearly in
March, is this an unreasonable assumption ?

I actually happen to support the ICCA journal (mostly). It would seem
a shame for its price to rise and its readership to fall when it *might*
be a simple matter to make more of the tournament total income
available to it by a tightening of the expenses paid.

You might even find there was some money left over to pay prizes.

But without publication of the figures, I, for one, would never know.

Chris Whittington

Tom Kerrigan

unread,
May 8, 1996, 3:00:00 AM5/8/96
to

Do Nobel's cohorts have a newsletter or a membership or hold conventions? Just
curious. I've never heard of such things, and if they don't exist then the
similarity with ICCA is pretty weak.

Also, I was wondering a bit about prizes. If the ICCA gets $20k before they put
one of these deals on, then I'm getting pretty confused as to where this money is
going. I mean, you can put at least two games in a hotel room. If a tournament has
30 entries and lasts 6 days and the rooms are $50 a night, that's "only" $4500.
With this setup, the programmers would have easy access to sofas and toilets, and
they would even have somewhere to sleep at night! Now I realize this is absurd,
but do tournament halls really cost 4.5x more than 15 hotel rooms? If they do,
maybe somebody should really start considering the former. :)

Cheers,
Tom

_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-

Going to church does not make a person religious, nor does going to
school make a person educated, any more than going to a garage makes a
person a car.

Chris Whittington

unread,
May 8, 1996, 3:00:00 AM5/8/96
to

kerr...@frii.com (Tom Kerrigan) wrote:
>
> Do Nobel's cohorts have a newsletter or a membership or hold conventions? Just
> curious. I've never heard of such things, and if they don't exist then the
> similarity with ICCA is pretty weak.
>
> Also, I was wondering a bit about prizes. If the ICCA gets $20k before they put
> one of these deals on, then I'm getting pretty confused as to where this money is
> going. I mean, you can put at least two games in a hotel room. If a tournament has
> 30 entries and lasts 6 days and the rooms are $50 a night, that's "only" $4500.
> With this setup, the programmers would have easy access to sofas and toilets, and
> they would even have somewhere to sleep at night! Now I realize this is absurd,
> but do tournament halls really cost 4.5x more than 15 hotel rooms? If they do,
> maybe somebody should really start considering the former. :)
>
> Cheers,
> Tom
>

I would posit that the tournament hall comes free. As do the PC's
and Work Stations.

This is guesswork but then I've been unable to find the costing figures.

Chris Whittington


Don Beal

unread,
May 15, 1996, 3:00:00 AM5/15/96
to

I have just become aware of some recent messages on this newsgroup about the
ICCA and the financing of computer chess tournaments.

Chris Whittington commented that he couldn't understand where all the
sponsorship money went at ICCA-organised events. He also commented that
the usual treasurer's report was absent from the most recent issue of the
ICCA Journal, and that the expenses element of tournament costs had not
been included in past reports.

As secretary and treasurer of the ICCA, I can supply this information.
It is certainly not being withheld intentionally.

First, there is nothing sinister behind the missing treasurer's report in the
March issue. Due to a misunderstanding over copy deadlines, this year's
report had to be carried over to the second issue. It will appear in
the June Journal.

Also, I would like to comment that the ICCA is a non-profit organisation run
solely by unpaid volunteers, mainly academics, including me. There are no
staff, although we pay a part-time secretary to typeset the ICCA Journal.
All income is spent directly on the activities of the ICCA, which are (1)
organising computer chess events, and (2) publishing the ICCA Journal.

Now the tournament finances.

I don't think Chris Whittington doubted this, but let me say first that the
sponsorship money goes primarily on the direct costs of making the event
happen. This usually includes travel and accommodation for non-commercial
participants (at most one person from each team entering), tournament hall,
hire of equipment, communications (the Hong Kong tournament last year needed
dedicated phone lines for some games - it was found that internet links were
overloaded when it mattered), etc. The details of this vary from
tournament to tournament. It is always done as cheaply as possible, with
as much local volunteer labour as can be found. There are usually no paid
helpers (except for some of the professional time of the TD) although some
expenses of helpers are paid.

The ICCA events often include a single banquet/reception for all
participants, which provides an opportunity to honour the sponsors and any of
their invited guests. (As one used to an academic lifestyle, this sometimes
seems extravagent to me!, but I accept it as part and parcel of the event.)

The ICCA also asks for, and gets, money for ICCA "sanctioning" of the event.

This money is charged by the ICCA for adding its "name" to the event. The
ICCA is seen by sponsors as an established, impartial (in the sense of not
representing any commercial interest), and authoritative organisation, with a
long track record of organising these events successfully. The sponsors are
willing to pay this fee. Most of the "sanctioning" money ends up being spent
on the ICCA Journal, which is an academic Journal, but also serves as a
newsletter for ICCA members. The Journal, and the academic foundations, give
the ICCA credibility as a "trusted organiser" and an impartial status, thus
contributing to attracting future sponsorship and sustaining a long-term cycle
of events and computer chess activity. This policy of subsidising the Journal
has been put to past ICCA general meetings and approved by the programmers
present. ICCA members get the Journal at about half-cost as a result.

Chris Whittington complained that the "expenses" element of tournament
costs was not given in annual treasurers reports. The annual report only
aims to give an overall financial snapshot of the ICCA, not a detailed
accounting for each event. However, in the hope that it may alleviate
any suspicion of secrecy, I am able to offer figures from the 8th World
Computer Chess Championship in Hong Kong last year.

From a total of around 100K of sponsorship value (mainly cash, partly
facilities supplied directly), about 3K was earmarked by a principal
sponsor for an honoured guest. About 2K went on a reception/dinner.
Travel and accommodation for playing participants was about 35K. Travel,
expenses and honorarium for the Tournament Director was about 4K. Travel
and expenses of the organisers was about 7K. Holding the ICCA triennial
meeting in conjunction with the event added about 5K (additional travel
and accommodation for 2 people). The ICCA sanctioning fee was 25K.
The rest of the money+facilities provided the playing site, communications,
local computers, and minor local expenditures. The above costs are high
because travel to HK was very expensive, but any location for a World
Championship will inevitably create high travel costs for many participants.

This means roughly 25% of the sponsorship value went to the ICCA Journal,
roughly 20% went on a variety of overheads, and roughly 55% went directly
into transporting participants and providing playing facilities. In addition
to the sponsorship there was also a tremendous amount of unpaid volunteer
work contributed by many people.

Don Beal.

0 new messages