Author: José Carlos
Date: 10:36:00 01/26/04
Go up one level in this thread
On January 26, 2004 at 13:14:10, Tord Romstad wrote: >On January 26, 2004 at 12:00:27, José Carlos wrote: > >>On January 26, 2004 at 11:10:55, Tord Romstad wrote: >> >>>On January 26, 2004 at 02:53:37, José Carlos wrote: >>> >>>>On January 24, 2004 at 17:12:45, Tord Romstad wrote: >>>> >>>>>On January 24, 2004 at 15:57:50, Mike Siler wrote: >>>>> >>>>>>In an average middlegame position, around 80-85% of the nodes my program >>>>>>searches are quiesce nodes. I have a static exchange evaluator and I only search >>>>>>captures with SEE value > 0. It seems like other engines are always under 25% >>>>>>qnodes. What else should I be doing to reduce these numbers? >>>>> >>>>>Use the SEE more aggressively. When the static eval is below beta, but >>>>>static_eval+(value of capturing biggest hanging enemy piece) > beta+margin, >>>>>return beta. This is too risky unless your SEE is very sophisticated. >>>> >>>> This doesn't make sense unless you do a real qsearch in your SEE, which is >>>>ridiculous of course. >>> >>>Yes. That is why I don't do this at all nodes, but only when the evaluation >>>function reports that the current position is "sufficiently close to >>>quiescent" that it is safe to rely on the relatively simple SEE. >>> >>>Consider the simplest possible example: >>> >>>Assume that the side to move has no hanging, pinned or overloaded pieces, >>>and that the opponent has an undefended hanging piece. If the static >>>eval plus the value of the hanging piece is considerably bigger than >>>beta, it is reasonably safe to return beta. This works even with >>>a very simple SEE. >>> >>>>Otherwise, you simply assume the opponent doesn't have a >>>>capture anywhere else on the board that can bring his score above alpha >>>>again. I do not understand why you assume that. >>> >>>You are right, the presence of hanging pieces for the side to move elsewhere >>>on the board is one of the conditions you should look out for when deciding >>>whether you should search the captures or just return the SEE value of the >>>biggest capture. >>> >>>Tord >> >> Thanks for the explanation. I was confused. >> I do something similar in Anubis, but instead of adding complexity to SEE, I >>check it at the top of qsearch. If material is way below alpha and the opponent >>can't make a capture that makes it near alpha, then I fail low. I can detect >>attacks with a simple bitboard lookup so that's pretty cheap anyway. I guess >>your gain comes from not needing to make() the move, but it wouldn't work for me >>anyway because I won't know about attacks until I make the move and update my >>bitmaps. > >No, avoiding the call to make_move() is just a tiny part of the gain. >I avoid having to generate moves, make the first move, call qsearch(), >evaluate the resulting position, and note that there is no capture >that can bring the score close to alpha. > >I save one call to generate_moves(), one call to make_move(), one call to >qsearch(), and one call to evaluate(). > >Tord Sorry, now I don't get it. You mean you do this before generating moves? So you enter qsearch, evaluate the position, check you don't have any hanging pieces, check the biggest enemy attacked piece, calculate a SEE for capturing that piece (you actually "generate" a capture here at least), test the expected gain against Beta+Margin, and if it is bigger you just fail high??? Sounds interesting. I always get suprised at how creative these young talents are... ;) I'm getting old. José C.
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.