Author: Uri Blass
Date: 06:49:00 12/19/02
Go up one level in this thread
On December 19, 2002 at 09:32:40, Martin Giepmans wrote: >On December 19, 2002 at 08:57:50, Uri Blass wrote: > >>On December 19, 2002 at 08:47:02, Martin Giepmans wrote: >> >>>On December 19, 2002 at 01:46:01, Uri Blass wrote: >>> >>>>On December 18, 2002 at 22:19:24, Martin Giepmans wrote: >>>> >>>>>On December 18, 2002 at 21:51:20, Omid David Tabibi wrote: >>>>> >>>>>>On December 18, 2002 at 21:44:09, Martin Giepmans wrote: >>>>>> >>>>>>><snip> >>>>>>>>>I don't understand what you are trying to say. >>>>>>>>>Without a research (if the verification search with reduced depth doesn't >>>>>>>>>give a cutoff) verification search would be pointless. >>>>>>>> >>>>>>>>The verification search goes deeper than the null-move search, so it might find >>>>>>>>tactical errors overlooked by the null-move search, and correct them (without >>>>>>>>any need for a re-search). >>>>>>>> >>>>>>> >>>>>>>No need for a research ?????????? >>>>>>>It's late, I guess we are talking about two different things? >>>>>> >>>>>>No we aren't :-) >>>>>> >>>>>>When we have a fail-high report, we simply reduce the depth, and continue a >>>>>>regular search, as if nothing has happened. Because this regular search (which >>>>>>can be called verification search) goes deeper, it might find out threats beyond >>>>>>null-move search's horizon. In that case, you would get the correct result even >>>>>>if you don't do a re-search! >>>>>> >>>>>Yes, we _were_ talking about 2 different things :) >>>>>My thing is verification search, yours is what I would call "de-extension". >>>>>One difference is that de-extensions are symmetrical (you reduce depth for >>>>>both colors) while (standard) verification search is essentially asymmetrical. >>>>> >>>>>I think it's possible that at least some of the readers of your article >>>>>got confused here and implemented something in their programs that you >>>>>didn't intend. Perhaps that explains why in many cases your method didn't >>>>>seem to work. >>>>> >>>>>Martin >>>> >>>>I do not understand >>>>How can you reduce depth for only one color? >>>> >>>>There is only one varaible with the name depth in my program. >>>> >>>>Uri >>> >>>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. > >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
This page took 0.01 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.