Author: Sune Fischer
Date: 03:12:59 07/01/02
Go up one level in this thread
On June 30, 2002 at 22:27:55, Russell Reagan wrote: >I'm curious if there are any schools of thought when it comes to computer chess. >Earlier today at work while I was trying to avoid working I was thinking about >two different approaches to developing an engine. One approach (which as far as >I know seems to be the most popular) is to pick your data structures based on >personal preferences, recommendations by more experienced developers, or >whatever the reason may be. > >I was reading over some CCC archives on my break and I read about how Vincent >was doing something in his program (attacks I think), and I saw how he was able >to do attacks very fast, but my other thought was that he surely put some >thought into how he wanted to evaluate positions before he decided upon what >kind of data structures to use. I've gone over a lot of the old posts too, it seems an AttacksTo table is not worth keeping in most cases. The incremental update takes too much time, and the information is (in Crafty) only needed for SEE and InCheck (I think). But, Crafty also doesn't do InCheck() in Qsearch so I guess pseudo legal moves are permitted in Crafty, the king can even be captured? I found this in crafty's notes 9.29... "* anyway. InCheck() is never called in Quiesce() now. as a * * result, Crafty won't recognize mates in the q-search. this has * * speeded the code up with no visible penalty, other than it will * * occasionally find a win of material rather than a mate score, but * * this has not affected the problem suite results in a measurable * * way, other than crafty is now about 10% faster in average type * * position, and much faster in others. the latest epd code from * " I presume the reason for this is the slow InCheck implementation, so the idea is to call the heavy functions as little as possible. I guess it is a trade off between speed and accuracy, Bob found this method gave a stronger program. I still like the idea of an AttacksTo table, it slows down move generation by a lot, but SEE, InCheck and probably some evaluation stuff become much faster. One really need to use that expensive knowledge generated for something more than just SEE and InCheck, or generating what ever needed info is faster to do on the fly. I think this is also the reason why AttacksFrom information is not saved in Crafty. >I believe the example was that he had an array that incrementally kept track of >how many pieces attacked a particular square, so when it came time to evaluate, >he had everything ready to go and I imagine he probably does other things like >this, and so his evaluation is probably very efficient. > >So approach number two would be to decide how you'd like to evaluate positions >and then decide which data structures best accomplish that. For example, if >mobility is a factor that you think is very important, then you should choose >data structures that make it possible to calculate that efficiently and not do >extra move generation and recursive calls to calculate mobility. I've often >struggled with how to approach deciding on which data structures to use, and >this seems to at least be a better method (maybe) of choosing data structures. >This (to me) seems like a better way than saying, "I'm going to use 0x88 because >it can do fast edge detection and attack detection." If fast edge detection and >attack detection aren't significant factors in your programs evaluator, then >this might not be a wise method of choosing your data structures. You are right, there has been too much debate about the speed of the move generation, there are other important functions such as SEE, GenerateCaptures, InCheck and evaluation. You can choose a part of the program you want fast, but then the other functions are likely to run slower. -S. >A final thought I had regarding this was that the ultimate wise decision would >be to choose the method that best suits your strengths as the programmer. For >example, let's say that ideally bitboards were the fastest (just for the sake of >discussion). Now, if your strength lies in programming ability, then that is >probably the right decision for you, since you will get the most out of that. >What if your strength is not programming though? What if you are a good >programmer, but your true talent lies in the ability to find abstract ways of >evaluating positions (IE ways that would work in a chess program)? If that is >your talent, then maybe you should choose the second approach (choosing your >data structures based on evaluation factors). > >I'm not entirely sure if any of this would work better in practice than current >methods, but I think it sounds good in theory anyway. I like the idea of >"playing to your strengths" though. > >Russell
This page took 0.01 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.