Author: Robert Hyatt
Date: 07:12:51 08/29/05
Go up one level in this thread
On August 29, 2005 at 06:02:09, Gian-Carlo Pascutto wrote: >On August 27, 2005 at 23:30:52, Robert Hyatt wrote: > >>On August 27, 2005 at 15:36:15, rasjid chan wrote: >> >>>On August 27, 2005 at 10:09:21, Jon Dart wrote: >>> >>>>> So this mean we don't need to keep pv[][] if we have hash tables (it is >>>>> like double accounting). >>>> >>>>I think this is false, given you have a finite size hash table and must >>>>eventually replace something. I have some experience: I used to retrieve pv from >>>>the hash table but now use a pv array and back up the scores. >>>> >>>>--Jon >>> >>>They tell me so and I begin to doubt. Maybe as Dr Hyatt says, backup the pv. >>>It may be best to be simple as I don't yet know how hashing twists and turns >>>within. >>> >>>Rasjid >> >>Just remember this. While searching the PV, _after_ you search a move on the PV >>path, you do a lot of other searching. Any of which can overwrite the PV move >>so that you get no move at that point, and a resulting short PV. The "back up" >>method has no significant cost associated with it, since it is not done very >>often in a PVS-type search... >> >>If you really don't care, the hash table approach works much of the time, and >>does have zero overhead. The array backup method has a finite but small >>overhead. I find that avoiding the short PVs helps in testing and debugging, >>but in real games is irrelevant with respect to the game outcome... > >What about setting a flag in the hashtable that it is a PV move and should not >be overwritten? > >I never did this, but thinking of it, why not? > >-- >GCP one reason: if you search to depth=30, you don't just have 30 PV moves. :) And I am talking about depth=30 as in the PV is actually just 30 plies long. But there are _lots_ of other moves that will look like PV moves, where you back a best move up, but then it gets thrown out. This has been tried in the past. And the problem is that you can and will end up with a _huge_ population of such positions at times, which basically reduces the size of the hash table to almost nothing, killing overall performance. All to get the PV that is easy enough to get by backing it up. :) I played with this a few years back, and someone suggested the "flag" idea. I was astounded at the number of such "PV" nodes that I found in the table just by running through every entry, after doing searches in problem positions...
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.