Author: Fabien Letouzey
Date: 06:20:45 03/25/04
Go up one level in this thread
On March 25, 2004 at 09:01:34, Sune Fischer wrote: >On March 25, 2004 at 08:32:05, Fabien Letouzey wrote: > >>On March 25, 2004 at 08:11:08, Sune Fischer wrote: >> >>>On March 25, 2004 at 07:47:02, Fabien Letouzey wrote: >>> >>>>> >>>>>So was I. You have only solved the problem along the PV. It _still_ exists >>>>>along non-PV moves just as I explained... >>>>> >>>>>this has nothing to do with aspiration issues... >>>> >>>>Yes of course it does not fix all the problems, I should have stated >>>>it. However I think I gain some "stability" (and a complete PV as a >>>>side effect) at the cost of a 1-ply search (sometimes more) all along >>>>the PV. For some reason, I did not consider turning hashing off >>>>everywhere in the tree :) >>>> >>>>The tradeoff in my design is that null-window searches can do what >>>>they want (forward prune, be inconsistent, etc ...), and the pv-node >>>>search will try to accomodate with that. >>>> >>>>Fabien. >> >>>I recall having read about something similar, namely extending the PV to make >>>sure the line is sound. >> >>>I believe the conclusion was that it didn't work so well, that the PV was no >>>more important than the refutations and there was no a priori reason to be >>>extending it. >> >>I have read this threat, but what I do is different. >Technically it is different, but I what I was trying to getting at, is that the >idea of using one type of search (more or less accurate) for PV nodes and >another type of search for the others, might not work(?). The search is not different; same depth everywhere, same quiescence, etc ... The only thing is that some values are not trusted and instead are recalculated. >It seems to me it could be a source of instability. Maybe, but I think not more unstable than trusting values with different drafts at PV nodes. I've had enough problems with those in the past. Furthermore Joachim Rang has run a series of gauntlet tournements which show no difference in strength (as compared with a version that probes "normally" at PV nodes), although I obviously have to search more nodes. >>There is no extra depth anywhere. >>My 1-ply thing is because I don't use hash-table values at PV nodes, so Fruit >>needs a 1-ply search to find it again (and 1-ply search at the PV node son etc >>...). > >"find it again"? Do you mean the PV move? No, the value. It is not trusted so it has to be "rediscovered" by a 1-ply search (or more). >Even if you don't want to cut on a pv you could still get the hash move to try. >Although I don't see a reason not to cut if the HT says cutting is fine. Of course I use the move for move ordering! One reason not to read the value is to have a complete PV. I have mentionned another one above. >>At each PV node (usually a single line), all siblings are searched. >I'm a bit fuzzy on the siblings, a PV sibling? >I don't think I know what that is. :) Me too, I should not be using it. I think you got my explanation about the 1-ply search along the PV anyway. Fabien.
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.