Author: Robert Hyatt
Date: 14:52:07 12/26/02
Go up one level in this thread
On December 26, 2002 at 17:08:37, Dieter Buerssner wrote: >On December 25, 2002 at 22:32:18, Robert Hyatt wrote: > >>Yes, but try it with best first ordering, which you can do after searching >>the thing to 22 plies and finding the win. Just search to 22 plies again with >>all the hash moves kept, but the scores cleared. No solution. > >This experiment would not prove the point (In the PV line, all black moves must >be searched - also the very bad ones, that are easily refuted). This will (with >fail-soft search) give many high scores in the HT. At the next depth, you can >take advantage of those scores (which are even there with perfect move >ordering). Some transpositions will be seen, that now can be forced in another >line, but still the depth of the bad lines before can be more than enough (the >new line is longer from the beginning). If you don't allow cutoffs (this is how >I interprete "scores cleared" - how else should I interprete it), you have a >different program, that does not take advantage of all this information. Note, >that the later point is independent of the move ordering argument. I simply mean "clear the table scores". I have a flag that says "worthless" in addition to EXACT, UPPER and LOWER. If the WORTHLESS flag is set, I can use the hash move, but not the score, ever. > >I will try the experiment anyway at some time, but after looking fast over the >code, I have seen, that for my engine it is not just a >"change-few-lines-in-one-minute" experiment. > >Some small point about the "bad design, if it depends on move ordering". Some >comments were given. Another subtle point is again the HTs. For many programs (I >think including Crafty), the decision about extension/pruning will depend on the >last move made. One example would be recapture. When you hit the HTs for a >cutoff, most probably the last move in this line was different, then at the >time, when you stored the position into the HTs. So, at this time, it is very >possible, that you would search the different ancestors of this node with other >search depth, than at the time it was stored. The consequences are, that this >can introduce another "luck factor" . > >I believe, for most (if not all) rather good programs, pruning/extensions >decisions depend on the window bounds (also in qsearch). It is quite obvious, >that with different move ordering, you will hit positions with different bounds. > >You are certainly well aware of the fact, that similar things happen because of >repetition detection and 50 moves rules. > >BTW. My "random move ordering" experiment for Fine 70 was done by disabling >detection of repetition. > >Regards, >Dieter
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.