Author: Volker Böhm
Date: 08:31:59 01/13/04
Hi, I´ve read in many posts, that SEE will speed up things when 1. Used for capture move ordering (ca. 10%) 2. Excluding "bad" captures from Q-Search (ca. 50%) 3. For ordering "bad" captures after killer and histtory moves (?%) I don´t use bitboards yet. It seems easier to "understand" chess programs without bitboards as you are able to implement stuff faster and less complicated. SEE will reduce speed, I wonder what I could gain. Some tests will show. At present I am thinking about it. I have allready a test if a piece is protected by a pawn. A queen hitting a pawn-protected rook is allways a bad capture. This is sorted after killers (I don´t have history-moves but a row of 6 killers). Is there a huge gain left with SEE? In qSearch I cutoff search if position_value + value-of-piece-to-hit + bonus < Alpha. I have only 30%-40% of nodes in qSearch (the horizont node is not counted as qSearch node). Seems impossible to gain 50% percent of total nodes, perhaps 50% of qSearch nodes. Am I wrong here? Isn´t it good to have a special qSearch SEE wich stops trying captures if it´s sure that the capture is < Alpha. Example: RxR, RxP; result <= value_of_pawn. I position_value + value_of_pawn + bonus < Alpha. This could be applied at horizont and qSearch. As horizont + qSearch get approx. 80-90% of nodes it´ll win much speed. Agree? I don´t remember reading this in crafty. But I havent red it too much as you tend to copy crafty instead of thinking on your own. A Question not really SEE, but cutting qSearch: I have an evaluation that begins to get lazy. I´m cutting part of eval if "current_value" (=material+pawn-eval+some-fast-eval) much less than alpha or much greater than beta. Obviously you can´t return the "current_value" from eval as it will be stored in hash and used later at other position with other window. A value < alpha is an upper-bound. So you wouldn´t make a mistake if returning alpha (if I remeber right, crafty is doing this). But returning alpha would reduce qSearch cuttoffs as position_value + any_capture gets > alpha! I´ve tested that the rest of the eval would´nt give positional values > 3 pawns (just recording the max of the eval-result in normal games) Thus I´ve implemented the following: if position-value-so-far + 3 pawns < alpha then return position-value-so-far + 3/2 pawns. It seems to work and don´t reduce the cutoffs too much. 3/2 pawns does make an error if used in hash on other situation, but is verry seldom. What do you think about it? Greeting Mangar (Volker Böhm, Germany)
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.