Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Search extensions and transposition tables

1 view
Skip to first unread message

Delphi

unread,
Aug 21, 2003, 5:52:50 AM8/21/03
to
Hi!

I'm planning to add transposition tables holding the usual values,
bounds and computed depth information of a position into my simple
chess program. As I use a simple search extension concerning checks
(adding 1 ply when a check occurs), I have a problem to understand how
the depth information in the TT could be used in such a case. If I
encounter a position where the hashprobe succeeds and the depth
information there says that the position was searched deeper before
than I plan to search, can this really be used in such a case? Because
with search extension, the moves to follow (if I would to the search)
could in fact increase my depth-to-do, making it (then) bigger than
the information in the TT. So it seems that some additional
information has to be stored in the TT, but what and how to use it?

Thanks for your help
-delphi-

Rudolf Posch

unread,
Aug 21, 2003, 2:19:39 PM8/21/03
to
Usually chess programs store positions into the transposition hash table
which have been searched full width (and many programs also positions from
the horizon depth too). Most programs do not store positions from the
quiescence search.
When you make a search extension like in your case extending 1 ply when in
check and you search this position with 1 ply deeper full width you can
save it in the TT hash table with the same good reason as any other position
searched full width.
Naturally you store in the TT in this case the increased depth.
Be careful to store in the TT not the depth distance from root but the
"draft", which is equal full width depth - actual depth.

Rudolf

"Delphi" <del...@kabsi.at> wrote in message
news:17730df9.03082...@posting.google.com...


> Hi!
>
> I'm planning to add transposition tables holding the usual values,
> bounds and computed depth information of a position into my simple
> chess program. As I use a simple search extension concerning checks
> (adding 1 ply when a check occurs), I have a problem to understand how

> the depth information in the TT could be used in such a case. ...


Delphi

unread,
Aug 21, 2003, 5:10:10 PM8/21/03
to
Thank you for your answer!

My problem arose when I thought of using such stored values (storing
also flags as EXACT or such):
a) Consider a situation in a 8 ply full search, where a line is 4
plies of non-checking moves and then 4 other plies with 2 checks in
it. According to my program it would then search a total of 10 plies.
Into the TT for the position after the first 4 moves I would enter the
returned EXACT value of this search and a depth information of 6 (= 10
- 4).

b) When later in the same iteration search I come to the same position
after 4 moves as above, there might be one check. For better
imagination think of a line that has a check in it and then of
transposing the moves such that due to the transposition the check is
avoided, which would be our first case of above. In the TT I would
find an entry and there is says: We searched this position before till
further depth 6 and got that and that EXACT value. So I could be
happy, because what I wanted to do, is search 4 further moves (8 - 4 =
4) and 6 were searched yielding an EXACT value, so I should simply
take it.

But if I compared this to what would have happened, when not the value
was taken, but the search made instead, then I see an inconsistency:
Due to the additional check within the first 4 plies I would in fact
search 11 (8 + 1 + 2) plies in total in case b). And of course, viewed
from our node in the TT, the search would have been *7* plies deeper
from there on and not 6.
So I wonder how could I ever take a value from a search till depth+6,
when it fact (really searching) I would have searched till depth+7,
which must not, but could produce a different value?
Do I not additionally have to take into account the 0 checks and the 1
checks within the first 4 moves of my above example?
I.E. wouldn't it be necessary to also store the number of "extending
moves" before a position in the TT and only if depth-till-leaf *and*
extending moves number are fulfilling the <= inequality could I simply
take the value?

Thanks,
-delphi-


"Rudolf Posch" <aon.91...@aon.at> wrote in message news:<3f450d39$0$18954$91ce...@newsreader02.highway.telekom.at>...

Match (schaakcommissie) account

unread,
Aug 23, 2003, 5:05:01 AM8/23/03
to
Is this really an issue?

Why don't you just store the remaining depth (what you at least want to
search), because having the same position the next time you probe it you
can compare the remaining depths of both. The new position that hit on
your stored TT-entry doesn't know on beforehand how many extensions it
wants to add anyway!

I think you're making it harder for yourself than it really is...

But then again, I might be wrong. ;-)

Renze
ftp://darkside.its-s.tudelft.nl/
http://darkside.its-s.tudelft.nl/

0 new messages