Author: Eugene Nalimov
Date: 11:10:49 06/24/99
Go up one level in this thread
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. 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.