Author: Peter McKenzie
Date: 23:46:50 06/15/02
Go up one level in this thread
On June 15, 2002 at 14:28:36, Christophe Theron wrote: >On June 15, 2002 at 13:44:06, Russell Reagan wrote: > >>On June 15, 2002 at 11:36:29, Christophe Theron wrote: >> >>>About the "fork" example: I would not treat it by evaluation. I have tried and >>>it does not work. The solution of this problem must be found in search or >>>QSearch improvements. >> >>Why doesn't it work? It seems to me that as long as you are able to hammer out >>the details of detecting forks and special cases you should be able to implement >>this (or any other tactical recognition) statically in the evaluation function. >> >>Of course, I have never tried it myself, so you surely know better than I do, >>but I'm curious if you could provide us with some information as to WHY it won't >>work. Is it because there are too many special cases to handle to make it >>accurate? >> >>Thanks, >>Russell > > > >It is because there are a lot of special cases to handle. If you want to >substract the value of a whole piece from your evaluation, you'd better be sure >about what you do, or else you will screw up many times. > >So it's hard to write and consumes a lot of processing time. > >You end up with something really expensive in term of processor time, that you >have to do at every leaf node or almost, and that is useful (if it works) only >in a tiny fraction of the positions you examine. > >It's a clear loser. > >There are more generic search algorithms, which take care not only of forks but >also of many other tactics, which are less expensive computationally, and which >are a much better solution for this problem. > >In general, trying to take tactics into account in the evaluation function is a >bad idea. In general, statements such as the above are a bad idea :-) You have a fantastic program, so you clearly have an approach that works. Great, but does that mean it is the only approach that works? I doubt it. You have tested many things, and obviously some work for you and some don't. Does that mean that the things which didn't work for you could never work, or wouldn't work for someone else? Of course not. A chess program is such a complex system of interworking components, that every program is different and what works in one might not work in another. The relationship between nullmove and q-search is a case in point. Maybe Bob's simple QSearch is why nullmove pruning wasn't great for him on slow hardware. One of the cool things about computer chess is the diversity of different approaches to the problem. Look at some of the top programs for example: Tiger, Fritz, Hiarcs, Junior, Shredder. I bet there is alot of variety in those programs! We have Fritz's big speed, Junior's weird search, Tiger's big pruning, Hiarc's slow NPS (who knows what he is doing), and Shredder which I don't know much about. And then there are even more 'way out' programs like CSTal, Diep, etc. Just my 2 cents worth. See you in Maastricht. cheers, Peter > > > > Christophe
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.