Author: Gerd Isenberg
Date: 15:19:13 01/13/04
Go up one level in this thread
On January 13, 2004 at 11:31:59, Volker Böhm wrote: >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. Really? For me it's the opposite, i like it setwise ;-) >SEE will reduce speed, I wonder what I could gain. Some tests will >show. At present I am thinking about it. Simply try it and see. > >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. A first step. But there are a lot of other simple cases, e.g. unsupported queen takes protected pawn, minor piece or rook and so on... >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? 3 pawns seems a bit to low ;-) > >Greeting Mangar (Volker Böhm, Germany) Cheers, Gerd
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.