Author: Frank Phillips
Date: 13:40:41 08/08/04
Go up one level in this thread
On August 08, 2004 at 15:53:17, Stuart Cracraft wrote: >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 It might be interesting to compare both approaches with a random odering. Never thought of mixing SEE and MVV/LVA for even captures. (What do you gain?) I tried pcsq for non captures and preferring those that did not hang a piece to a pawn, but both seemed detrimental in the main search -although since the tree changes it is always difficult to tell.
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.