Author: Reinhard Scharnagl
Date: 22:55:59 08/31/04
Go up one level in this thread
On August 31, 2004 at 20:37:00, Rick Bischoff wrote: >[...] >That is all just superflous though, because the engine WASTES time searching >when the recapture is obvious-- how can you describe such a concept in code? Let's view that from a very extrem point: why calculate at all on a move when already knowing that it for sure would be best? The dilemma is, that the "knowledge" of "best" moves may be intuitivly right but often fail in fact. When chess GMs talk they mostly would think only on very few moves they are applying to such a type of expert pruning. But a chess engine is only then such an "expert" after having calculated a lot on all moves. Already in the early beginning of chess computer programming it had been noticed that it would not make much sense to calculate when only one single move answer has been possible. But even then a perfectly precise calculated evaluation has mostly been investigated, though it does not help at all to decide here. Calculate preferred best estimated evaluations for positions is ONLY A HELPING METHOD to find out the "best" move and not a goal for itself. But looking at some engine protocols will show the opposite being standard: an engine seems to be forced to always communicate detailed evaluation figures. Though still having no solution for that request of a GUI to support it with the demanded values (I do not want to supply it with random numbers) I am trying in Smirf (hope to be finished this year) not to calculate "precise" figures but simply drive the DECISION MAKING PROCESS to a satisfying point. Because it is sufficient to find out the "best" move, its "exact" evaluation does not really matter (except e.g. for analysing tasks). Regards, Reinhard.
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.