Author: Miguel A. Ballicora
Date: 12:06:05 08/31/01
Go up one level in this thread
On August 31, 2001 at 13:06:06, José Carlos wrote: >On August 31, 2001 at 12:15:07, Robert Hyatt wrote: > >>On August 31, 2001 at 11:15:33, Steve Maughan wrote: >> >>>Bob, >>> >>>>>Or are you defining a PV search as any search that could result in a PV from >>>>>the root? >>> >>>>Yes to your last question. This is a "hard" search to do, and without good >>>>move ordering, it becomes harder still. Hence the internal iterative deepening >>>>to help it out. >>> >>>OK. If this the case then can't you detect a PV node as: >>> >>> PV When (beta-alpha)>1? >>> >>>Regards, >>> >>>Steve >> >> >>Not quite. This will think that when you are searching some non-PV move deep >>in the tree, but below the first move at the root, and you fail high on that >>move, you would have that case. I'm not sure (without thinking about it a lot) >>that I want to trigger IID everywhere this happens. Right now what I do is >>probably overly conservative... > > Here's what I do (dunno if it's any better): > I have 5 search functions: > - Pensar: which performs the iterative deepening, running a loop increasing >depth until time is over, and calling PVS(depth). > - PVS: which controls the search at the root. Performs a special move ordering >and calls AlfaBetaPV (for PV move at the root) with aspiration window and >AlfaBeta (for the rest of the moves) with Alfa,Alfa+1. It also controls fail >high's and low's, and moving up or down the search bounds. > - AlfaBetaPV: standard alfa-beta search with IID but not null-move. It calls >AlfaBetaPV(Alfa,Beta) for the first move, and AlfaBeta(Alfa,Alfa+1) for the >rest. Also, if any of these second moves fail high, it calls itself, >AlfaBetaPV(Alfa,Beta) and checks if a new PV move is reached. > - AlfaBeta: search function for the non-pv moves. It gets only a bound (Alfa) >and sets a local variable Beta, which is Alfa+1. It doesn't do IID. It does >null-move. It _always_ calls itself (AlfaBeta) with the actual Alfa. > - QSearch: no need to explain this. > > This way, I always know where I am, and I can easily do different tasks (if I >want) with PV and non-PV nodes. I think that sooner or later I will do something similar and I was thinking about it very seriously. The reason I want to do it is because I want to try different move ordering schemes for each function without making search() a real mess to detect where I am in the search. So far I have all the ones you have but the one you call AlfaBetaPV. The only real disadvantage I see is that is more difficult to maintain, since it will be necessary to update the code in many places when I want to make a change that is common to all the "searches". In theory, it should be bad to have similar functions doing similar things because it will thrash the cache, but actually AlfaBeta and Qsearch are the only ones that are call frequently. Maybe your approach is even better since it will be possible to make AlfaBeta() smaller without the overhead of making distinctions if you are in PVnodes or not. Regards, Miguel > > Hope this helps, > > José C.
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.