Author: Ratko V Tomic
Date: 16:13:16 10/23/01
Go up one level in this thread
> But what would this have to do with searching the position _below_
> a hash entry and then storing that as well? It won't get hit if
> the current entry is hit first.
It won't get hit in that particular subtree. But with the kind of
low material reversible positions and depths of 10+ plies, what is
below in one sequence can easily be above in another. We are not
talking about human player trees, but trees with 99.99... percent
of pointless back-and-forth, that need to be weeded out.
>I don't see how the "best" move can fit into "one bit or less". If
>you have to have large external dictionaries, etc, then the cost of that
>has to be included as well. I think that practically, an 8 bit index is
>the minimum that can be _safely_ used, because we know there are over
>128 possible moves in many positions, but so far, never more than 255, so
>that 8 bits will work for all cases. This won't save a thing until the
>deeper mates in 6 piece files overflow to 16 bits (or 12 bits or whatever
>is considered reasonable).
The best-move would not work by merely fetching the move index
for a dumb move generator. Rather it could work as a correction
to a specialized endgame engine/s which could play all by itself
a decent endgame. (Even at 20 ms per move, which is quicker
than a few disk accesses for a single egtb file lookup, todays
programs could give a hard time to most humans.)
Note that the "best move" isn't a synonim for the move which leads
to shortest mate (or the longest delay in getting mated). As
long as the engine can produce a line which wins with certainty,
it doesn't matter if it may take more than the minimum number of
moves, it won't affect the program's strength (rating, or ratio
of won to lost points). The entire classes of endgames could be
thus be encoded in a small piece of specialized code (e.g. code
which knows where and how to squeeze king to some particular
corner) with possibly a bit of helper lookup tables providing
exceptions to the more general algorithm. In such case you would
need maybe 20-30k vs 200 Mb or some such bulk of data for the
distance-to-mate tables for that type of endgame.
The corrector role of the best-move tables could also be
used to tweak the evaluation parameters/tables for the engine
so it can produce the "best move" ("best" in the weak sense,
i.e. one that wins while using minimum amount of correction
data, not the shortest move to mate). One could use the
distance-to-mate tables as the input to the best-move tables
generator, the way one uses raw data points to compute the
coefficients of the best-fit polynomial of a desired fit quality.
One doesn't need to fit exactly every point, but merely to
satisfy the criteria of generating one of the winning moves
quickly (as opposed to one which wins the most quickly).
The best-move tables thus act as the exceptions to the large
number of simple rules with quick evaluations (from human
endgame theory or machine extracted from the raw distance
tables), where the rules would cover the bulk of positions
with sufficient accuracy.
The point of my comments was that the best-move approach allows
for beneficial use of any knowledge and patterns (due to
do their proximity to the patterns), while the distance-tables,
which are far away consequences of the composition of many
steps, cannot.
>I/O is horribly slow. I would _never_ do 100 now, on the hopes
> that I will use a few of them again later. The right way is
> "always put off until later that which you can do without
> now, because later might never come if you get a good cutoff."
Well, I wasn't talking about 7-bit/best-move tables where you need
100 lookups on the disk to follow-up the sequence. The specialized
best-move generator for particular type of endgame may be loaded
once that type of endgame is within reach of searches. Its corrective
data may be compact (e.g. rules for some rook endgames) so it
needs few reads for the entire operation of that module.
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.