Author: Johannes
Date: 03:57:15 04/07/05
Go up one level in this thread
On April 06, 2005 at 11:40:11, Robert Hyatt wrote: >On April 06, 2005 at 07:37:55, Johannes wrote: > >>Hello! >>Right now im working on a new Version of my Chess Engine and an idea has come to >>my mind, but i dont know if its applicable: >>When I'm in Q-Search i only want to deal with material values. I handle theses >>incrementally, so theres is no need for any function call except the Q-search >>recursion. >>After returning from Q-Search (at the full-width horizon) i simply add the >>positional eval score to the score returned from Q-search. This score is >>returned "up the tree". >>For the positions before the horizon this should be no problem concerning >>alpha/beta values etc... . Also positions beyond the horizon should not suffer >>from this, as long as the alpha/beta values were not passed to a Node before the >>horizon before. If they were, the alpha/beta bounds would not be correct, >>because they include positional scores which are not considered beyond the >>horizon. >>So my idea is to simply substract the local positional score from the alpha/beta >>values (as long as they are not -INF or +INF) at the full-width horizon, before >>entering Q-Search. I assume that this would result in correct cutoffs. >>Is this idea correct? >>I didnt find any drawbacks yet, but i only have a vague intuition about it. >>I really would appreciate if anybody could help me with this. >>greets >>johannes > > >You can "cheat the system" however you want. In this case, you are positionally >evaluating the board, and then making captures that could greatly change that >positional evaluation, but you won't realize it. > >For example, a capture that shreds the king-side pawn structure will not be >scored correctly since you won't realize that the king-side is destroyed, >because you use the positional evaluation before the capture is made and just >factor in material only after that point. Ditto for endgame ideas such as a >pawn running after all pieces are exchanged. If you evaluate the position >before the exchanges, the pawn can't run, if you then make the exchanges and >think all is ok, you will lose. > >It is a dangerous road... Hi there! Thanks for the quick responses. Of course your right about the problems with missing information in the Q-Search. The background to my idea is the following: Q-Search was always intended to be a safety measure to prevent unstable board positions from being evaluated. Therefore I'm trying to put as less effort (CPU-Time) as possible in it, e.g. dealing with material scores only safes time here. This increases my full-width horizon. I think this the tradeoff im facing here. The Q-Search is bad informed, but in my opinion it should safe me from the Horizon Effect in the first place. The problemes you mentioned are really the only ones i can think of. There are positions where the win/loss of one piece can greatly influence the static positional score. In this positions the score returned from full-width horizon wont be correct, because a capture beyond the horizon would have this influence (although the capture is already considered in the material term). Im going into a bit more experimenting on this idea, because i think it would be nice to find a way to perform the Q-Search as cheap as possible. I dont want to be informed by Q-Search, i just want the safety of a stable material score. greets johannes
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.