Author: Hermano Ecuadoriano
Date: 08:48:44 02/04/01
Go up one level in this thread
On February 04, 2001 at 08:27:24, Dieter Buerssner wrote:
>On February 02, 2001 at 21:10:54, Paul wrote:
>
>[I wrote something wrong]
>>>I think, especially with EGTB mates, it is quite possible
>>>that it is not an upper limit, and that with higher depth the opponent may
>>>by able to find a refutation, that delays the mate.
>
>...
>
>>Is there a difference according to you between 'normal' mates found by a search
>>without using EGTB's, and mates found by a search that is using EGTB's? If so,
>>what? And if not, then normal non-EGTB-search-mates are not an upper bound?
>
>The above was obviously wrong, and I was seriously confused - sorry. After
>thinking another while about this, I have no idea anymore, how I came to the
>idea above ...
>
>As also confirmed by Robert Hyatt, the mate score should allways be exact
>or an upper bound.
Since I'm not an expert, my verbiage might not be right.
In the old days of full width programs and alpha-beta only we had provably
shortest mates. (This interesting question was proven.)
Now, with forward pruning, these can't be provably shortest (unless the
program goes back and proves it, full-width A-B).
Furthermore, they can't be upper bounds: in the above position different
programs announced mates of different depths, using the tablebases. They
can't all be upper bounds. (At last I get to use my education.)
Some evidence:
snip Crafty .log
White(1): setboard 8/6kn/3B3p/5K1B/8/8/8/8 b --
(snip text board display)
(Next is my first attempt to make a diagram in this forum!)
[D]8/6kn/3B3p/5K1B/8/8/8/8 b - -
Black(1): go
end-game phase
time surplus 0.00 time limit 1000:00 (1000:00)
nss depth time score variation (1)
9 0.70 Mat68 Kg8 Kg6 Ng5 Be2 Ne6 Kxh6 <HT>
10 1.34 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
10-> 1.35 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
11 2.67 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
11-> 2.69 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
12 5.61 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
12-> 5.63 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
13 13.85 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
13-> 13.87 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
14 40.59 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
14-> 40.62 0.01 Ng5 Be5+ Kh7 Bf4 Nh3 Bxh6 <HT>
15 51.75 -- Ng5
15 1:59 Mat72 Ng5 Be5+ Kf8 Kg6 Ke7 Bg7 Ke6 Bxh6 <HT>
15-> 2:01 Mat72 Ng5 Be5+ Kf8 Kg6 Ke7 Bg7 Ke6 Bxh6 <HT>
1. That Mat68 was not an upper bound!
2. It was not proof that there was ANY mate: if it can change it's mind at
ply 10, it could change it at ply 16.
The tablebases are being reached by different paths, and are being probed
with different positions.
I think this is an important misunderstanding (which should be explained to
the user). In the past, and in popular usage, a mate announcement was an
exact solution.
Mate Prover
A built-in mate prover, like Chest with tablebases, would be a nice feature. (It
could be configured to confirm mate scores automatically if desired.)
Then, the score could be given properly as e.g. +999 until proven. But
because it is full-width, it would often be practically unable to reach the
depth at which the forward-pruning program found the tablebase. Another way
could be to backsolve from the position with which the tablebase was probed.
(Thus every tb mate-score could also return that position, in case it needs
to be proven.)
Finally, assuming I'm right about the above, I'll say one more thing.
It is clearly possible for one move in the movelist to score a -MATX (which
could turn out later to not be mate at all), while the next move in the
movelist does not find the tablebase, and is thus chosen to avoid the mate.
(This is exactly what happened at ply 10 above.) This might be unavoidable,
because we don't have time to look at everything. But here is one more point,
which is why I posted: one could score -MATX, and another -MAT(X+Y).
Now THAT could confuse the search.
END
>
>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.