Author: Roberto Waldteufel
Date: 07:26:50 06/30/98
Go up one level in this thread
On June 30, 1998 at 07:32:40, Ulrich Tuerke wrote:
>On June 30, 1998 at 06:33:12, Guido Schimmels wrote:
>
>>Does anybody use a refutation table for move ordering ?
>>When you already use killer and history heuristic, is a refutation table
>>of any further benefit ?
>
>I think that the term "refutation table" has been used in literature in 2 ideas
>with slightly different meanings.
>
>1. There are the "butterfly tables" suggested by Hartmann & Kouwenhoven in 1991,
>where whenever a cut occurs you store the corresponding move into a table which
>is indexed by the preceding move. I have worked with this for several years. It
>seems to me that it does result in a modest improvement in move ordering. The
>draw-back is that it's a little bit memory intensive ("cache-hostile"). Omitting
>these tables on a K6 makes my program at least 10% faster concerning nodes/sec.
>I doubt that the benefit thru slightly improved move ordering is worth this slow
>down and I'm seriously considering to remove these tables now.
>
>2. There is another (older) refutation heuristics suggested by Akl & Newborn in
>1977, where (provided I remember right) the subsidiary variation to each of the
>root moves is stored and used. My prejudice is that this became obsolete with
>the use of massive transposition tables cause you have these moves in the hash
>table anyway.
>
>My conclusion is that these ideas are worth a try in cases where for some reason
>only limited hash tables are available, but in general these attempts are
>obsolete. But this is only a personal prejudice, didn't really run huge test
>cases, only a few positions (for both of the above cases).
>
>Regards, Uli
>
>>Before I waste my time with excessive testing I would like to know
>>about your experiences. Thanks !
>>
>>- Guido -
The hash table moves that give you the subvariations can also be used to produce
the main PV from the root node, thereby avoiding the need to explicitly store
the PV during the search. There is a very small chance of a node on the PV being
overwritten if the hash table is large, but to be safe I store the best move at
the root separately, but use the hash table for the rest of the PV. I found this
a little faster than before, when I maintained the PV throughout the search.
Roberto
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.