Author: Omid David Tabibi
Date: 02:55:04 11/22/02
Go up one level in this thread
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 ? > My program used only the standard methods as described in the section "Experimental Results". I wanted the results to be as generic as possible, and so didn't use any extensions except a one ply check extension at leaf nodes. The quiescence consisted of only captures/recaptures. >BTW assuming my program has searchinstabilities instead of realising that you >used a woodcounter that may be too simple to reflect the impact on the >architecture of a real chessprogram isn't a nice thing to do. > I don't use the word "instability" to blame any program for something ;-) Instabilities are natural in any complex system like a chess program; and that is why a "not so obvious" idea like verified null-move pruning might not work at first trial, before tuning the program. > >> >>Tony >> >>> >>> >>>>Tony >>>> >>>>> >>>>> >>>>>>Tony >>>>>> >>>>>>> >>>>>>> >>>>>>>>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.