Author: Stuart Cracraft
Date: 12:53:17 08/08/04
Go up one level in this thread
On August 08, 2004 at 06:38:47, Frank Phillips wrote: >On August 07, 2004 at 16:44:51, Stuart Cracraft wrote: > >>On August 07, 2004 at 15:28:07, Michael Henderson wrote: >> >>>On August 07, 2004 at 13:50:46, Stuart Cracraft wrote: >>> >>>>On August 07, 2004 at 13:47:41, Dan Honeycutt wrote: >>>> >>>>>On August 07, 2004 at 13:40:16, Dan Honeycutt wrote: >>>>> >>>>>>On August 07, 2004 at 13:00:31, Stuart Cracraft wrote: >>>>>> >>>>>>>So I heard a lot about SEE from a lot of people >>>>>>>and was fortunate enough to receive some good code >>>>>>>from Alessandro. I implemented and tested it with >>>>>>>many test cases and in all cases it gave the >>>>>>>expected return from the exchange ok. >>>>>>> >>>>>>>Then with some other help I implemented this in >>>>>>>the capture search. >>>>>>> >>>>>>>This program has some things that make SEE() not >>>>>>>give a good result, in fact slightly worse (fewer >>>>>>>nodes in same time) -- no speedup. >>>>>>> >>>>>>>1) evaluator is material and pc/sq lookup only >>>>>>>2) routine to find attackers/defenders (to give to see) >>>>>>> is not much faster or slower than makemv() >>>>>>>3) I order all moves partly with MVV/LVA but do not >>>>>>> discard directly on that unless the alpha/beta/pvs >>>>>>> says to disard/cutoff. >>>>>>> >>>>>>>With these, the program did not speedup with SEE >>>>>>>and slowed down. The program is PVS with null move. >>>>>>> >>>>>>>So that is the story -- I will leave the code in >>>>>>>for a future day and future need. >>>>>>> >>>>>>>If someone with #1 and #2 got a good speedup from SEE, >>>>>>>let me know. I am doing something wrong in that case. >>>>>>>Or if you think there is some other way SEE can be used >>>>>>>advantageously, let me know. Currently I only have it >>>>>>>in the capture search since that's where I heard it had >>>>>>>the most effect. >>>>>>> >>>>>>>Stuart >>>>>> >>>>>> >>>>>>Stuart: >>>>>>What captures are you discarding in qsearch? ie >>>>>> >>>>>>if (see < 0) discard_capture; >>>>>>if (see + standpat < alpha) discard_capture; >>>>>>if (see + standpat + margin < alpha) discard_capture; >>>>>> >>>>>>You may want to tinker with this some. For me the third one with a margin of a >>>>>>pawn or 2 works best. >>>>>> >>>>>>Dan H. >>>>> >>>>> >>>>>I should add I also do: >>>>> >>>>>if (mvv_lva + standpat + margin >= alpha) keep_capture_and_skip_see; >>>>> >>>>>mvv_lva is victim value - attackor value. >>>>>Dan H. >>>> >>>>Dan - thanks for the input. What value of standpat do you use? >>>>(Assume the see() routine does all its internal standpat >>>>in its minimax.) >>>> >>>>Stuart >>> >>>Are you using SEE to order captures in the non-qsearch? >> >>I tried these (both worse than no SEE for me) >> >> SEE to order captures in qsearch and non-q search >> SEE to avoid searching losing captures altogether in qsearch >> >>Stuart > > >I am surprised that SEE ordering does not help the main search. Most captures >are considered by the search are stupid. Problems are atypical since they >usually involve tossing material, so I think you have to be careful when drawing >conclusions from test suites. > >Of course, SEE is not perfect, since it ignores pins etc. (or at least mine >does). A very good question. In my addmove routine which adds a pseudolegal move to a list as part of the general move generator (and the capture generator), I have it simply calculate the score's move, if capture, based on mvv/lva along with a small positional centrality term based on piece type and include also the history heuristic score for this move, if any. If the move is a non-capture, then all except mvv/lva. I compare the above with an approach where instead of using mvv/lva alone, I used see also. If the see is zero, then I use mvv/lva and the rest as above. If the see is non-zero, then I use the see value and the resta as above. The comparison gave a better result for the SEEless approach for short searches of 1 second on an ancient 1ghz P3. I have not done tests for deeper searches with the above although deeper searches have shown a 50% move reduction and time reduction for fixed depth searches as compared with not using see,for the case when see is not used to order moves in addmove but instead to throw out negative see moves entirely in the quiescence (and no where else.) Anway, that's what my program's result was. SEE helps more if you don't have good move ordering already. Even MVV/LVA is quite good. True that SEE would put losing captures at the bottom, below almost everything else, but apparently this isn't that important for some weird reason I can only guess at. Stuart
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.