Author: Vasik Rajlich
Date: 04:45:00 01/07/04
Go up one level in this thread
On January 06, 2004 at 15:09:50, Tord Romstad wrote: >On January 06, 2004 at 13:44:08, Russell Reagan wrote: > >>On January 06, 2004 at 13:34:31, Tord Romstad wrote: >> >>>This is *way* too pessimistic, IMHO. Writing a top engine is of course >>>an enormous task, but creating something that plays legal and mostly >>>sensible moves is only a moderatly complicated task. >>> >>>If you know the basic theory when you begin, writing a simple engine >>>should take something like a couple of months in a low-level programming >>>language like C or Java, and a couple of weeks in a high-level language >>>like Lisp. >> >>If you don't worry about the speed of your program at first, you can get >>something up and working that plays sensible moves very quickly. I know this >>from first hand experience. I've wasted years trying to write the absolute >>fastest code :) >> >>Do yourself a favor (the original poster), and don't worry about how fast your >>program is at first. Worry more about learning how game playing algorithms work >>and implement them and experiment with them. Once you become familiar with this >>stuff, you can learn some clever methods for how to do things efficiently and >>make your program fast, and you can probably rewrite your program completely in >>a very short time (a few days or weeks, depending upon how much time per day you >>can spend programming). > >This is very good advice. Almost all beginning chess programmers (including >myself when my engine was very young) overestimate the importance of speed. >In fact, I would claim that there is no reason to spend much time on >low-level optimisation before your engine is within 100-200 points of the >top engines. Before you reach that stage, there are much easier ways >to improve your engine. It is much better to concentrate on implementing >and tuning chess knowledge and on improving your search. Making your >engine 50% faster (as measured by nodes/second) without sacrificing >knowledge, portability, readability or ease of modification is usually >really hard. Improving the average branching factor slightly is much >easier (in the early stages of development), and also much more effective >(because the improvements are exponential rather than linear). I more or less agree with this, but there is one caveat: when you first begin, you have to decide whether to use bitboards or not. If you don't, you'll never switch to them without a complete rewrite. Based on my experience so far I would strongly recommend using bitboards. They are not that complicated, they were not so difficult to debug (as I had slightly feared), and quite a number of evaluation terms can be very elegantly & efficiently expressed with them. For example, I use a bunch of precomputed masks to test for various pawn & piece configuration around the king. I have offline code which precomputes each of these masks, and creates a .h file of "const BitBoard weak_sq_g4_p = 0x..", and when each of these is used in eval the compiler will substitute it at compile time. Vas > >Sometimes I even feel that incompetence is an advantage when doing computer >chess programming. When you don't know how to program, you are forced >to focus on high-level stuff, which is where the greatest scope for >improvement is found. > >Tord
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.