Author: Carlos del Cacho
Date: 02:25:17 01/28/01
Go up one level in this thread
On January 27, 2001 at 19:24:41, Tony Werten wrote: >On January 27, 2001 at 19:00:30, Carlos del Cacho wrote: > >>On January 27, 2001 at 16:43:05, Tony Werten wrote: >> >>>On January 27, 2001 at 16:34:53, Carlos del Cacho wrote: >>> >>>>On January 27, 2001 at 14:30:18, Severi Salminen wrote: >>>> >>>>>Hi! >>>>> >>>>>I made a few test games between a version of my engine using SEE and another >>>>>using just MVV sorting. I played only a few (24) games and time control was >>>>>5min/G and in 8 games 1min/G. The result was 12-12! Is this possible, normal, or >>>>>do I have a bug? I would have guessed that the SEE version had beat the hell out >>>>>of the other but that never happened. It seems that SEE slows things down a lot >>>>>and the net result seems to be that it searches equally deep compared to the >>>>>other version. Has anyone here measured the true benefit of using SEE? Could you >>>>>show me positions in which SEE makes a big difference or could you run self-test >>>>>games between two versions of your program? Are there positions where SEE hurts >>>>>searching? I really like to know if SEE is worth it? I have a relatively slow >>>>>computer (300Mhz Celeron, Crafty running at 80KNPS) so could time control and >>>>>overall speed have influence on this? >>>>> >>>>>Any comments are welcome! >>>>> >>>>>Severi >>>> >>>>Just a quick test. Two runs on WAC 5 sec/problem: >>>> >>>> - SEE pruning in Quiescent Search: 270 >>>> - without it: 246 >>>> >>>>So it is definitely a win for my program (Pepito). >>>> >>>>The only difference between these builds was commenting out these lines: >>>> >>>> val = SEE(pos_stack->jug); >>>> if (val < 0) >>>> continue; >>>> >>>> val += MARGEN_QUIES + pos_eval; >>>> >>>> if (val <= alpha) >>>> continue; >>>> >>>>But you should note that I try not to call the SEE function whenever possible. >>>>If I can get a cut with pos_eval + mat_gain I give up this capture. Another >>>>question is if SEE is profitable in normal search. I also it there but kicking >>>>it out would be a bit more difficult so I haven't tried yet :-). At the same >>>>time captures are generated I assign them their MVV/LVA scores. Then I try >>>>captures with positive scores and when this gets below zero I call SEE for >>>>remaining moves. Losing ones are searched after all non captures. I'm not really >>>>sure about the gains here so I'll give it a try... >>> >>>I'm a correct in assuming you don't do checks in qsearch and your MAX_EVAL < 2 >>>pawns ? Because in that case SEE is definitly a win ( maybe also if you do some >>>checks and max_eval is a bit bigger than 2 pawns ) >> >>Yes. I don't include checks in quiesce. I rely in check extensions in normal >>search. And my evaluation function can only get positional values over 2 pawns >>in the endgame so I should disable this there. > >I think so. Disabeling lazy eval should help you in the endgame. (Or actually: >lazy eval should hurt you in the endgame ) ( just an opinion ) Mmmmm... I still use lazy eval in the endgame, but after pawn evaluation. So it shouldn't hurt much, I think. SEE pruning surely hurts (been doing some tests :-) ). Carlos > >Tony > >> >>Carlos >> >> >>> >>>Tony >>> >>>> >>>>Greets, >>>>Carlos
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.