Author: Eugene Nalimov
Date: 13:52:23 06/24/99
Go up one level in this thread
Not automatically, if (1) killer is not a capture, or (2) it's losing capture. If the threat is the attack to your king, probably both of you have a lot of pieces that are under the attack. So, after your capture, it's probably better for him to continue the kingside attack than try to recapture. Of course without the experimental data we can "waive our hands" (or how to say it in English) very long. Ok, here is the next idea I proposed to you some time ago, but it was not incorporated in Crafty: if alpha/beta bound is "Mate in N plies", and we started to search ply N+1, we can fail low/high immediatelly, without further searching. Test itself is very simple, and should help in solving problems "Mate in N". I am not sure how benefitical it'll be in the real play, but test itself is very simple - 2 comparisons and 2 branches for x86. Eugene On June 24, 1999 at 16:00:34, Robert Hyatt wrote: >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.