DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: R T

⟦0ea5bcf10⟧ TextFile

    Length: 2865 (0xb31)
    Types: TextFile
    Names: »README«

Derivation

└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987
    └─⟦this⟧ »EUUGD18/General/Chess/README« 

TextFile


C source for CHESS

Here is a shar script containing source code in 'C' for a chess 
program I've written. The following files are included: 
  1. chess.c   : C source for CHESS
  2. chess.opn : Opening Library
  3. chess.001 : Sample problem
  
The file chess.c must be compiled with the -lcurses option. The 
code is pretty generic (I think) and hopefully will run on a wide 
variety of machines. The help command gives a list of the options
available.  To test out the program, enter 'get' and respond to
the file name prompt with 'chess.001'.  Type 'switch' and the
computer should find mate in 4 with Nf7.  This takes a few seconds
on an HP350 computer.

The program plays a fairly respectable game of chess, although it 
is not competetive with a state-of-the art commercial program. The 
search rate is typically 100-300 nodes/sec. on an HP Vectra (8 Mhz. 
286) and about 300-900 nodes/sec. on an HP 350 (25 Mhz. 68020). I 
am interested to find out what is achieved on other machines. I 
would also be interested in any comments on playing strength, 
weaknesses or bugs in the program, and suggested improvements in 
the algorithm. 

Here are a few comments on the program:

1. Opening Library
     I'm a terrible chess player and don't know anything about 
     openings. I copied 70-80 random lines of play from MCO into 
     the file chess.opn. I think there are a few mistakes in the 
     translation. If anyone generates a better library please let 
     me know. 
     
2. Positional Heuristics
     I think that improvement in this area would help the program 
     quite a bit. In most situations the computer cannot do
     anything forceful and the choice of a move is based on 
     positional aspects. I haven't spent a lot of time on the 
     heuristics and many times the program has no idea of what is 
     happening and how to proceed. Perhaps optimizing the values of 
     the existing heuristics would help, but to get a major 
     improvement I think more chess knowledge will be necessary. 
     
3. Search Algorithm
     This program uses a full-width alpha-beta searching technique 
     with depth extensions on checks, check evasions, pawn promotion
     threats and threats to multiple pieces. Capture sequences are
     handled by a separate search routine. I imagine that much more
     efficient search routines exist, and would be interested to hear
     of any. Refinements of the search extension heuristics (similar
     to the extensions for pawn promotion threats) could have a major 
     effect on the programs ability. 
     
4. Move Generation
     There are probably better ways to do this, but they would 
     likely change the data structure drastically and necessitate 
     a complete re-write. Maybe some good hacks would speed things 
     up, the ataks function would be the best place to start.