Author: Dezhi Zhao
Date: 14:16:52 03/02/06
Go up one level in this thread
On March 02, 2006 at 11:40:51, Robert Hyatt wrote: >On March 02, 2006 at 00:48:59, Dezhi Zhao wrote: > >>On March 01, 2006 at 15:51:29, Robert Hyatt wrote: >>>I increment the fail high count by 100 each time a move fails high. I also >>>increment the tried count by 1 at the same time. Any time another move fails >>>high, and this move was tried but did not, its tried count gets incremented, >>>which lowers the "failed high percentage" significantly... >>> >>>sort of: >>> >>>if failed_high(x) >>> x.count++ >>> x.fh+=100 >>> >>>if failed_high (y) (later) >>> y.count++ >>> y.fh+=100 >>> if (tried(x)) x.count++ >>> >>>Hope that makes what I am doing clearer, whether it is good or bad is not >>>certain yet... >>> >>> >> >> >>why not keep it simple?! >> >>Suppose x is any move we just searched. >> >>x.count++ >>if failed_high(x) >> x.fh+=100 > >That grossly biases the statistic downward. You can either count: > >(a) times a move was searched anywhere vs the number of times it failed high >(that ratio will likely be very high, as fail-highs are not that common) > >(b) times a move was searched and didn't fail high when another move did, vs the >number of times it was searched and did fail high. That seems to be a more >useful comparison, because now we can say "something failed high, but not this >move..." > >In case (a) there are plenty of times when all moves fail low, particularly when >move ordering is very good. And the count value will be very high, but the fh >count will be very low. That would say this is an ok move to reduce. In case >(b) if something fails high but this move doesn't, then that is more useful to >know how many times that happened vs the cases where this move failed high >itself. > >Intuitively it seems better. Whether it actually is or not has not been tested >by me (yet). As for (b) approach, it seems to me that you're trying to get some locality out of a global killer (or history) table. This is somewhat foreign to history table. If results of (b) are not much better than (a), you may have a good reason to consider the history killer table I mentioned in another post in this thread:)
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.