Author: Heiner Marxen
Date: 05:31:38 03/23/04
Go up one level in this thread
On March 22, 2004 at 16:55:23, Dieter Buerssner wrote:
>On March 22, 2004 at 12:11:19, Heiner Marxen wrote:
>
>>I have not yet looked at fruit source, but from my own recollection how
>>to do ETC... in Chest I restrict the usage of ETC to non-trivial depths.
>>If the expected work without ETC probing is too small, the overhead of
>>ETC is does not pay off. May be fruit does restrict it in such a way,
>>that even the additional overhead of move make/undo is small compared
>>to the potential savings.
>
>Are you using any search extensions in Chest?
No, definitely not. The basic function of Chest is very tightly coupled
to a real "ply depth". A mate in 3 is at most 5 plies deep... in every
branch, otherwise it would _not_ be a mate in 3, right?
Recently Franz Huber tried some extension-like ideas ("special" mate mode)
and promply we had "funny" inconsistencies. We had to completely give up on
some of his ideas, which looked quite promising, at first.
> I think, this is a real problem
>for a normal playing engine. Assume some "mate threat extensions" (decision for
>such an extension for example by doing a shallow search after a null move). I
>see no method, to keep the extensions consistent for ETC, without doing that
>search again. And now, this is not only a makemove, but a real search with many
>makemoves ...
I'm not sure I really understand...
I understand that extensions are decided upon along with moves, sometimes
after the move has been executed, already. And just inspecting the resulting
board is not always sufficient to decide whether an extension has been done
at the last move, so we have to extend first, and only then have to look
into the TT.
For ETC this means (in order to be able to decide whether the depth in the TT
is sufficient) we have not only to compute the hash resulting from a move,
but also the extensions we would do for it... what may be a problem.
Is this what you mean?
For Chest this is no problem at all, fortunately ;-)
Therefore I havn't yet thought about this problem: it just did not occur to me.
I suspect that easy to calculate estimates (upper and lower bound) will
fail to decide the most frequent case of a hash hit... but what about
the even more frequent case of a cache miss? Cache hit rates are typically
below 20%, so 80+% of the TT lookups should be decidable with the hash code
alone, right? Depth estimates could decide some more cases, and the rest
would need something more sophisticated.
Hmmm... if we really have to make a move in order to decide a TT hit,
this destroys a large part of the benefits of ETC... :-(
>Already keeping normal extensions (that do not depend on a new search, only on
>the position and previous moves) consistent seems not easy, for a "grown"
>engine, that did not think of encapsulating search extension decisions in a
>function, but rather has it all over the place in a long search routine.
>
>It might still be an idea that works, when some special searches are included to
>calculate extensions.
Something like a restricted 1-ply search? Sounds kind of complicated,
and does not pay off near the leaves of the search tree.
>Cheers,
>Dieter
It never occured to me that ETC could be so complicated! Ouch!
Cheers,
Heiner
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.