Author: Omid David Tabibi
Date: 09:18:38 11/22/02
Go up one level in this thread
On November 22, 2002 at 12:01:54, Uri Blass wrote: >On November 22, 2002 at 11:40:35, Tony Werten wrote: > >>On November 22, 2002 at 10:59:33, Uri Blass wrote: >> >>>On November 22, 2002 at 10:52:03, Omid David Tabibi wrote: >>> >>>>On November 22, 2002 at 10:47:00, Uri Blass wrote: >>>> >>>>>On November 22, 2002 at 03:46:06, Tony Werten wrote: >>>>> >>>>>>On November 22, 2002 at 03:31:37, Uri Blass wrote: >>>>>> >>>>>>>On November 22, 2002 at 02:59:34, Tony Werten wrote: >>>>>>> >>>>>>>>On November 22, 2002 at 02:44:52, Tony Werten wrote: >>>>>>>> >>>>>>>>>On November 21, 2002 at 17:01:11, Omid David Tabibi wrote: >>>>>>>>> >>>>>>>>>>On November 21, 2002 at 16:55:04, Tony Werten wrote: >>>>>>>>>> >>>>>>>>>>>On November 21, 2002 at 16:19:17, Omid David Tabibi wrote: >>>>>>>>>>> >>>>>>>>>>>>On November 21, 2002 at 16:05:45, Tony Werten wrote: >>>>>>>>>>>> >>>>>>>>>>>>>On November 21, 2002 at 13:52:33, Omid David Tabibi wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>On November 21, 2002 at 13:05:28, Uri Blass wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>On November 21, 2002 at 09:16:09, Omid David Tabibi wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>On November 21, 2002 at 08:34:36, Uri Blass wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>1)I do not find in the pseudo code in figure 3 undo null move. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>I assume that it should be before if value>=beta and after value=-search(...) >>>>>>>>>>>>>>>>>Am I right? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>That is why it is called *pseudo*-code :-) >>>>>>>>>>>>>>>>You have to fill in the obvious parts by yourself... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>2)What is the value of the research for tactical strength? >>>>>>>>>>>>>>>>>Should it help significantly relative to searching to reduced depth when >>>>>>>>>>>>>>>>>value>=beta without research (even when we get value that is less than beta). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>I didn't understand the question. Dp you mean doing a shallow search even when >>>>>>>>>>>>>>>>we don't have a fail-high report?! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>I meant to ask what is the tactical value of the research(You suggested people >>>>>>>>>>>>>>>to start with doing it without the research first and only after it works to do >>>>>>>>>>>>>>>it with the research) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>The re-search is needed only in zugzwang positions. Such zugzwang positions >>>>>>>>>>>>>>occur very rarely in midgames; so you can forgo the zugzwang detection re-search >>>>>>>>>>>>>>and still benefit all the improved tactical performance. >>>>>>>>>>>>> >>>>>>>>>>>>>I was quite surprised to see them from the starting position at a rate of 5 per >>>>>>>>>>>>>second. Not impressive, XiniX searches 400 Kn/s there, but still surprising. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>The rate of what, was 5 per second? >>>>>>>>>>> >>>>>>>>>>>"Zugzwang positions" or rather, positions where nullmove would have given a >>>>>>>>>>>cutoff but that after reducing depth and searching gave a score < beta. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>You mean you got an average of 5 zugzwang indications per second in middle >>>>>>>>>>game?!!! Then your program has instabilities which cause a huge number of >>>>>>>>>>needless re-searches due to false zugzwang alarm. Turn off your zugzwang >>>>>>>>>>detection at once! >>>>>>>>> >>>>>>>>>I'm quite interested in finding out what is happening so I'll leave it in for a >>>>>>>>>while. I think it has something to do with tempo. XiniX doesn't use futility >>>>>>>>>pruning so I'm quite curious to know if programs that do, have a bigger false >>>>>>>>>zugzwang count. >>>>>>>> >>>>>>>>Think I found it. Your algoritm doesn't seem to work correctly with threat >>>>>>>>detection, causing instabilities. Maybe your testprogram didn't use it ? >>>>>>> >>>>>>>I do not understand >>>>>>> >>>>>>>Can you explain? >>>>>>> >>>>>>>I did not find something strange with the 5 "Zugzwang" per second in the opening >>>>>>>position because I assume that it is all about the horizon effect and not about >>>>>>>real zugzwang positions". >>>>>> >>>>>>Yes, and R=3 gets the horizon closer than R=2. Threats fe get found easier with >>>>>>R=2. >>>>>> >>>>>>Tony >>>>> >>>>>I now checked with movei and counted 63 horizon effects in the first 10,000,000 >>>>>nodes. >>>>> >>>> >>>>By 63 horizon effects you mean zugzwang detection (they are two different >>>>things!)? >>> >>>The algorithm does not detect zugzwangs but cases when null move search return >>>beta and search to bigger depth returned a value that is smaller than beta. >>> >>>I do not believe in zugzwangs near the opening position so I guess that the >>>reason must be some horizon effect. >> >>I looked at some of the positions and they weren't zugzwang positions. So my >>best guess is also horizon. Probably combined with "tempo" wich is quite >>important in the beginning. >> >>Tony > >It seems that I had a bug of initialized local varaible >First positions was no zugzwang > >36 positions out of 10,000,000 if I have no bugs now. > I think it is still too much. The acceptable average should be less than 5 in 10 million nodes. Remember that each such position is re-searched with the original depth; that is a huge overhead. I still think that you should turn off zugzwang detection before the other parts work fine. >Uri >> >>> >>>Uri
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.