Author: Don Dailey
Date: 10:44:09 06/19/98
Go up one level in this thread
>I would be very interested to know what >were the features that Larry recommended for your preprocessor, and whether any >of these things were later moved to the terminal evaluation to improve accuracy, >albeit at the cost of some speed. Pawn structure was not preprocessed because it is too important. With hashing techniques you can get good and fast pawn structure anyway so we chose to use this. No matter what you do there is a fight between speed and knowledge. Preprocessing allows speed while still being able to have a significant amount of knowledge. This is balanced against the annoying problems it has with search context. I created a language for Larry to write the preprocessor rules in. It allowed fairly natural descriptions of patterns and chess concepts. I had subroutines, variables and many other real language features in it and Larry quickly was able to master it with only a few examples from me. This was a wonderful tool because Larry could fix any problems he saw in the positional play without long conversations with me and requiring me to implement it and download versions back and forth. Back in those days modems were about 1200 baud I think and the whole process was a little tedious and subject to error. The language produced an intermediate type of "machine code" which REX was able to quickly process. After getting used to a preprocessor you find lot's of clever ways to simulate various pieces of knowledge. It's tricky business because you are often anticipating things that might happen and dealing with them based on assumptions that may not be true. This is the same way humans do it too. But we covered pretty much all the "chess fundamentals." We had lots of endgame stuff, and preprocessing is nice for covering patterns, like recognizing a certain type of middlegame and having a plan to deal with it. Specific endgames are (usually) easy to cover too. We had lots of code for specific positioning of pieces. We had code to encourage rooks to pry open files, get pawns passed (but not to recognize them, the dynamic pawn structure did that) and a lot of nice king safety stuff. We knew a few typical king safety patterns. We encouraged pawn storms when kings were castled on opposite wings and had several "plans" built into the preprocessor to deal with lots of awkward situations like getting your rook into the game when it was on h1 and the king was on g1. We had a rule to recognize that Bf1 was not so bad if you were castled and your rook was developed. These little things eventually would make a lot of difference in how it played because we covered situations that actually occured in real games. I am still sort of an advocate of preprocessing. I think it should be used sparingly as programs get faster and faster but you can really get a lot of nice knowledge with virtually zero cost. Maybe someday it will not make sense but I still think that is still in the future. For those that advocate a more human approach to computer chess I would argue that this is a very human algorithm. We get most of our ideas and plans from a direct consideration of the starting position. I also think that is a limitation of the human approach but that is a different post! As it stands now in my opinion, a judicious mix of preprocessing and dynamic evaluation with more emphasis on the dynamic might be the best way to go. I would like to say this is a highly subjective opinion on my part and have no wish to debate the point so I hope no one flames me for saying this. It's just a guess on my part. Having said all of this, I will now say that all my recent programs do not make use of the flexible preprocessor. I am still dreaming of a way to get all the benefits without the drawbacks but haven't found this yet! I am looking through some old diskettes looking for the source code for REX and other older programs. I am afraid I may have lost this stuff. If I find it I will email the "rulebase" to you. It would be fun to reimplement it (I think it would be easy for a progammer to implement the code directly without having to recreate the language) or simply get some ideas from it. Larry was a genius at creating these kind of rules. He had the right combination of being a strong chess programmer and having the ability to elucidate this knowledge. - Don
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.