Author: Stuart Cracraft
Date: 14:27:01 01/21/98
Go up one level in this thread
On January 21, 1998 at 00:04:35, Robert Hyatt wrote: >On January 20, 1998 at 23:02:11, Stuart Cracraft wrote: > >>On January 20, 1998 at 22:52:25, Stuart Cracraft wrote: >> >>>On January 20, 1998 at 19:21:48, Bruce Moreland wrote: >>> >>>> >>>>On January 20, 1998 at 18:43:19, Robert Hyatt wrote: >>>> >>>>>I'm sorry, but this is insane. What is the purpose of doing a hash >>>>>probe? >>>>>To eliminate searching the positions you already know the outcome of, >>>>>right? >>>>> >>>>>But instead, you are searching *first* and then looking up *second*? Of >>>>>what use is that lookup? You have already done the search.. So throw >>>>>that >>>>>lookup out and go even faster, because it can't possibly provide any >>>>>info >>>>>that the search you just completed did. >>>> >>>>You are making the same mistake that I did. The pseudo-code isn't doing >>>>what you think it is doing. >>>> >>>>If he's in search, and is at depth < 0 (or whatever), he's calling >>>>quiescent search and *returning* that value. >>>> >>>>So what this boils down to is that he's not doing a hash probe at the >>>>root of quiescent search. Whether or not he's doing hash probles inside >>>>quies (even at the root, which would mean doing it twice), I don't know. >>>> >>>>Before you say, of course it makes sense to not hash quiescent nodes, I >>>>think this varies from program to program. >>>> >>>>bruce >>> >> >>That's right Bruce. I don't do hash probes in the quiescence search >>nor before the call to the quiescence subroutine in the full-width >>routine when depth <= 0 as that would mean I would be doing hash >>probes below the full-width level, e.g. in quiescence. >> >>My current arrangement >> extensions >> null move >> if (depth <= 0) >> return(quiescence(...)); >> transposition table probe >> full-width processing here >> >>So naturally I don't want to probe the transposition table >>BEFORE the if statement above as that would mean I would be >>doing transposition table probes at a depth below full-width, >>e.g. in the quiescence. That was the bug in this arrangement >>of the code. The probe had to go AFTER the if statement to >>get the probe out of the quiesnce. >> >>(An odd result. On a SUN Unix box, this results in a 20% speedup >>in nps. But on a plain DOS PC (actually a WinDoze 95 in >>Restart-in-DOS-mode) it results in only about 2.5% speedup.) >> >>--Stuart > > >that makes more sense, but it is a *very* bizarre search formulation. >The thing written by Ken Thompson years ago makes the code much more >readable and understandable. IE I can't get to Search() if depth is == >0 >so that test is not needed in mine. Whenever depth==0 I go directly to >quiesce.. As I recall, Thompson's paper in Advances in Chess 3 had something like: Search() .... if (depth - 1 > 0) Search(....,depth-1) else Quiesce(....,depth-1) So his Search routine was never called for any upcoming depth of 0. For that, the dispatch went straight to Quiesce. Technically, his formulation saves some subroutine-call overhead (e.g. avoiding the superfluous call to Search() if the new depth will be 0), and may be clearer. I haven't tested the two to compare the speed difference but I'll bet it's pretty small, but since we're bumming code, yeah, I guess it's better. I have used it in the past from time to time. On the readability count, I can go either way. No preference. --Stuart
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.