Author: Robert Hyatt
Date: 08:44:07 11/19/02
Go up one level in this thread
On November 19, 2002 at 05:12:40, Sune Fischer wrote: >On November 18, 2002 at 18:15:03, Robert Hyatt wrote: > >>On November 18, 2002 at 16:15:03, Sune Fischer wrote: >> >>>On November 18, 2002 at 13:23:01, Robert Hyatt wrote: >>>>>Not necessarily. I do that, but before calling qsearch I get the chance to check >>>>>for draw, see if there is a hash or egtb table hit or if I should do some >>>>>further extensions (ie. this way I don't enter qsearch when in check!). I don't >>>>>do any of this in qsearch. >>>> >>>>I don't enter quiesce() if in check either, however I also avoid tacking on the >>>>procedure call overhead. If you want to do all that, just move it down in your >>>>search code to just before you call quiesce. You get the _same_ effect, without >>>>an extra procedure call thrown in. >>>> >>> >>>Well, like I said I do more than that, but the main reason why I decided on >>>accepeting this "overhead", was so that I wouldn't have the same segment of code >>>repeated 7-8 times as in Crafty. I believe it is easier to maintain the >>>following simple structure: >> >>I'm not sure what you mean "repeated 7-8 times". My repetition/hash/egtb code >>occurs exactly one time in search() and nowhere else... > >Yes, but you don't do it before going into qsearch, so you only have makemove(), >extensions(), eval(), makemove(). Normally everywhere else in the program you >have probe_hash(),draw(),makemove(),extensions.... So your last ply is not a >full ply IMO. I don't follow your math. If I do a 9 ply search (assuming no extensions here) I don't ever probe at ply=1 as that is useless, but I do probe at plies 2 through 9. I don't see how my last ply is "not a full ply" as I do everything at the last ply that I do at every _other_ ply in the full search.. > It might be better to do it like you do, I don't know, but other >than the overhead I don't see a reason to skip the potential cut off tests. > >My idea was, that since we have depth=0 there is a good chance a hash hit can >give a cut off, also the repetition detection is so cheap that we might as well >try that one last time before going into qsearch also. There's no problem in doing that. In fact, there would be no problem in having a special "leaf node" quiesce() module that does those things, but then calls the normal quiesce() for the rest of the q-search below that point... > >>Ditto for search extensions as they occur right after MakeMove() is called, >>prior >>to the recursive call to Search or Quiesce... > >I counted 6 calles to Quiesce() in Search() (Crafty 18.15), I need only 1 call >:) Are you doing (a) internal iterative deepening? (b) null-move search? those account for three distinct calls. (c) PVS? that requires three overall. One for the first move, Potentially two for any move but the first, since the null-window search can fail high and it must be re-searched. None of those are "repeated" or "duplicates"... > >-S.
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.