Author: Robert Hyatt
Date: 13:00:34 06/24/99
Go up one level in this thread
On June 24, 1999 at 14:10:49, Eugene Nalimov wrote: >Ok, returning to the original subject: it looks that the move that caused >null-move search to fail can be a capture, in which case it will not be stored >as a killer. Or, if it is not a capture, you'll try it after the all the winning >captures. > >Maybe it's better to try that move after: >(1) PV/hash table moves, >(2) Winning captures that captures the piece that was just moved. > In my case, this is automatic. I try the hash table move, then good captures, then killers, etc.. so I don't allow capture killers because they would be picked up with the capture search that is done first. >I.e. if null-move failed, there is a seriuous threat; and it's better to try >that threat early, after you tried to refute opponent's move by obvious actions. > >Eugene > >On June 24, 1999 at 09:31:34, Robert Hyatt wrote: > >>On June 24, 1999 at 04:50:01, Ed Schröder wrote: >> >>>>Posted by Robert Hyatt on June 03, 1999 at 22:44:02: >>> >>>From an older posting.... >>> >>>>>Should a hash table move precede the PV? >>> >>>I always understood "PV move" = "hash table move". >>> >>>What is the difference? >>> >>>>I don't have a "PV" option. After each iteration, the first thing I do >>>>is 'stuff' the PV moves into the hash table... which means that following the >>>>hash table move will suck me right down the PV as I want... all without having >>>>to have _any_ special code in the move ordering stuff... >>> >>>"Stuff the PV moves into the hash table", what does this mean? >>> >> >> >>When you search the first move, the PV from that search _should_ be in the >>hash table. But by the time the rest of the moves are searched, it is more >>than just probable that some of those positions have been overwritten as >>the rest of the tree is searched... >> >>To make _sure_ that the PV moves are in the hash table when the next iteration >>is started, I 'stuff' them in. I do this by following the PV, looking up each >>position, and if I don't find it in the hash table, I store what should be there >>again... so that when the next iteration starts, I will find every PV position >>and run down that path first... >> >>If you don't 'stuff' you will not always follow the PV from the last search, >>because if _any_ hash entry (for the PV moves) was overwritten, you have to >>revert to normal move ordering, which likely won't be the "pv move".. >> >> >> >> >> >>>Maybe we have you can explain about your definition of PV as we >>>might have a different one :) >> >> >>PV = principle variation. PV moves are those moves from the previous search, >>best path, as displayed when the best score was found. But it is not guaranteed >>that these positions (which are definitely stored in the hash table as the PV >>is backed up) will survive to the start of the next iteration. They can easily >>be overwritten, particularly those near the end of the PV as they will have a >>shallow 'draft' and be likely candidates for replacement. >> >> >> >> >>> >>>Ed Schroder >>> >>> >>>>The other answer is 'yes' pv should come first... but if done right, the >>>>PV should be in the hash table, so there should never be a 'choice' anyway...
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.