Author: Martin Giepmans
Date: 07:40:43 12/19/02
Go up one level in this thread
<snip> >>>>That's right, but the effect is asymmetrical. >>>>It's the same with nullmove. >>>>Suppose a program has white and only uses nullmove on ply 2. >>>>The effect is that it may overlook a good continuation for white, but >>>>_not_ for black. Nullmove pruning is (in effect) asymmetrical. >>> >>>If it only use null move on ply 2, but programs do not do it. >>>> >>>>Standard verification search (always research) is also asymmetrical. >>>>If you leave out the research it becomes symmetrical: it may >>>>overlook good continuations for _both_ sides. >>>> >>>>I think there is a fundamental difference between vs with and without >>>>research. >>> >>>I agree that there is difference but not because of not symmetric searching but >>>because it is possible that the research gives you better information at the >>>cost of time. >> >>It's not so easy to figure this out, but my hunch is that verification of >>nullmove without research is in fact incorrect. >>What is verified in this case? Nullmove pruning? Not exactly ... > >without research it is simply a negative extension. >I do not see what is not correct with negative extension. Nothing wrong with negative extensions as such. But in this case the negative extension is supposed to correct (at least some of) the shortcomings of nullmove and nothing else. I think it does something else. If that is really a problem is another question. I don't know. I seems that verification without research is akin to threat extensions. Threat extension: extend if the nullmove doesn't produce a cutoff. Verification without research: de-extend if the nullmove produces a cutoff. (de-extend only once in the case of verified nullmove) Looks OK, but it's not verification. Maybe we should change the name. Martin > >> >>Of course I know that many things that we use in our programs are not >>100% correct. "search instabilities", hmm, I don't like them, do you? >> >>Martin > >I have search instabilities but the question is if it is possible to avoid them >and do the program better. > >I found a case that my program could find some tactic at depth x but not at >depth x+1 or x+2(only at depth x+3 it could find it again) > >I found it simply by telling it to increase depth in a specific node. > >I found that when I increase depth by one or two it suddenly cannot find the >tactics and only when I increase it by 3 it can find it. > >I suspect that I cannopt avoid it if I want to do my program better. > >Uri Yes, I have similar sorrows! Martin
This page took 0.02 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.