Author: Koundinya Veluri
Date: 12:35:58 10/05/01
Go up one level in this thread
On October 04, 2001 at 13:37:25, José Carlos wrote: >On October 04, 2001 at 11:01:08, Tim Foden wrote: > >>On October 04, 2001 at 10:55:32, Paul wrote: >> >>>On October 04, 2001 at 10:41:30, Tim Foden wrote: >>> >>>>On October 04, 2001 at 10:11:36, Paul wrote: >>>> >>>>>On October 04, 2001 at 07:03:14, Tim Foden wrote: >>>>> >>>>>>Hi All, >>>>>> >>>>>>I decided that I would add a 2nd SEE to GLC to check whether GLC's SEE was >>>>>>working. I actually ported GCP's Sjeng SEE (that was posted to the forum a >>>>>>while ago). >>>>>> >>>>>>Both SEE routines now agree in most curcumstances, but one's like the following >>>>>>have cropped up (where they disagree): >>>>>> >>>>>>[D]5rk1/1pp2R1p/p1pb4/6q1/3P1p2/2P4r/PP1BQ1P1/5RKN w - - 2 0 >>>>>> >>>>>>This can be evaluated in 2 ways... >>>>>> >>>>>>(1) BxP (+1000) BxB (-3500) R1xB (+3500) QxR (-5500) RxQ (+10000) RxR (-5500) >>>>>>.........+1000.......-2500........+1000.......-4500........+5500...........0 >>>>>> >>>>>>>>> value = 0 >>>>>> >>>>>>(2) BxP (+1000) BxB (-3500) R7xB (+3500) RxR (-5500) RxR (+5500) QxR (-5500) >>>>>>.........+1000.......-2500........+1000.......-4500.......+1000.......-4500 >>>>>> >>>>>>>>> value = -2500 >>>>>> >>>>>>So... on to the questions: >>>>>> >>>>>>a) Does anyone's SEE do anything intelligent in these cases? >>>>>> >>>>>>b) Is one of these right, and the other wrong? If so, which one? >>>>>> >>>>>>c) Do we actually care, as long as the SEE works in the majority of cases? >>>>>> >>>>>>Cheers, Tim. >>>>> >>>>>I haven't studied SEE yet, but shouldn't (2) also result in a value = 0, since >>>>>you don't have to take the pawn being white? I mean, you start with a value of >>>>>0, right? >>>> >>>>Yes, you start with a value of 0. In this particular case I think that (1) >>>>above is best. But should a SEE routine care? I mean... maybe this kind of >>>>thing doesn't occur often enough to worry about. I'm not sure about this, so >>>>I'm asking questions to see if anyone else has a better idea. >>>> >>>>Cheers, Tim. >>> >>>No, I guess I didn't make myself clear ... I meant: why do you say value=-2500 >>>in case (2) and not value=0? I thought that SEE worked in such a way that you: >>> >>>(a) play out all the captures for both sides to the end, and then >>>(b) work your way back to the front to see where each should stop capturing to >>> max its own result. >>> >>>Now if you do that for white in case (2), shouldn't (b) result in white not >>>capturing anything and so value=0? >> >>No. You always make the first move in the SEE. You are trying to find out the >>predicted value if you make the first move. The higher level code will make the >>decision whether it is actually worth making the move in the first place or not. >> >>So if we are in this position in the q-search, then Bxf4 will be one of the >>moves that the q-search considers. Before it actually makes a recursive call, >>it asks the SEE what value it thinks it would get for the move. If the SEE says >>< 0, the q-search prunes the move. >> >>Cheers, Tim. > > Just a question (haven't implemented SEE yet): will you always return if >SEE(move)<0 or do you have kind of a threshold?. For example, if the SEE returns >-1 pawn, the positional eval can still raise that above 0, making it worth >trying, true? > > José C. I guess that would be specific to each program. If one program's eval often goes above a pawn's value, then probably you should use -1 as the threshold, but in my program I found that it is actually slower with -1 because my eval stays below a pawn's value most of the time and the rare case when it does go above a pawn's value isn't worth looking at in the qsearch, IMO. Koundinya
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.