Author: Robert Hyatt
Date: 18:08:37 08/11/04
Go up one level in this thread
On August 10, 2004 at 23:49:07, Stuart Cracraft wrote: >On August 10, 2004 at 23:33:01, Robert Hyatt wrote: > >>On August 10, 2004 at 21:59:39, Stuart Cracraft wrote: >> >>>On August 10, 2004 at 12:52:28, Robert Hyatt wrote: >>> >>>>On August 10, 2004 at 10:59:29, Tord Romstad wrote: >>>> >>>>>On August 10, 2004 at 10:35:29, Anthony Cozzie wrote: >>>>> >>>>>>Plus, if you have only PST eval you should be getting 3-4M nps, so SEE probably >>>>>>slows you down a _lot_. >>>>> >>>>>Yet another proof of how bad my programming skills are. With PST eval and >>>>>nothing >>>>>else, I get about 800,000 nps (on a PIV 2.4 GHz). Adding SEE slowed me down to >>>>>around 750,000 nps. >>>>> >>>>>Tord >>>> >>>> >>>>SEE slowed me down by 10%. Move ordering improved to speed me up 10%. Washed >>>>out to no advantage, _until_ I added the stuff about tossing out captures that >>>>can't bring the score back to within the alpha/beta window. That made me about >>>>2x faster overall, which is a _big_ gain. Stuart isn't getting all the >>>>advantages of SEE yet, and, in fact, It isn't necessary to use SEE on _every_ >>>>capture. IE for PxQ there is no need to see if that is +9 or +8. Either is >>>>good enough and there MVV/LVA is faster. >>> >>>Then the question that is begged here is about "added the stuff about tossing >>>out captures that can't bring the score back to within the alpha/beta window." >>>I take this to be similar at what you hinted when you said if the capture >>>gets me back a pawn but I'm a queen down, why bother? >>> >>>So are you talking about, in quiescence in move loop: >>> >>> while next capture >>> if material_evaluation_after_this_capture + MARGIN < alpha >>> skip >>> else >>> if (see()<=0) skip >>> else >>> makemove >>> search >>> unmove >>> fi >>> fi >>> endloop >>> >>>where MARGIN is like 2 pawns or something? >>> >>>Stuart >> >> >>In Crafty MARGIN is calculated, and represents the largest positional score >>produced during this game... >> >>But that is the basic idea... The first test is wrong as you can't base >>anything on just the value of the captured piece. IE QxR might bring the score >>back in the window but if the R is defended, you don't want to examine that >>capture in the actual search. > >Okay, but I'm not using see (that's after it avoids the delta cut) so there >must be something else. Yo uhint that the capturer might be captured so >that leads one to believe one should evaluate for both but then we're >talking about minisee. > >Should I just include see there instead > > while next capture > if see + MARGIN < alpha > skip > else > makemove > search > unmove > fi > fi > endloop > > >Finding the defender of the captured piece is not hard but it is >a call to my attack/defense finder which is ugly and expensive >(only slightly less so than the see which uses it.) > >Stuart The only way the first test will work is if val(mvv) > val(lva). Then you _know_ you are winning material as even if the attacker is re-captured outright, you still are ahead...
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.