Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Extending Checks

Author: Ed Schröder

Date: 03:13:32 09/13/04

Go up one level in this thread


On September 13, 2004 at 04:53:10, Gerd Isenberg wrote:

>On September 13, 2004 at 02:55:22, Ed Schröder wrote:
>
>>On September 12, 2004 at 23:54:18, Robert Hyatt wrote:
>>
>>>On September 12, 2004 at 17:39:45, Ed Schröder wrote:
>>>
>>>>On September 12, 2004 at 13:22:52, José Carlos wrote:
>>>>
>>>>>On September 12, 2004 at 06:50:50, Ed Schröder wrote:
>>>>>
>>>>>>On September 11, 2004 at 11:47:35, José Carlos wrote:
>>>>>>
>>>>>>>On September 10, 2004 at 21:35:58, Stuart Cracraft wrote:
>>>>>>>
>>>>>>>>I read, somewhere, and I forget who, about
>>>>>>>>if 1 legal move, extend 2 ply,
>>>>>>>>2 or more legal moves, then 1 ply.
>>>>>>>>Anyone have any stats on the effects
>>>>>>>>on play of the above instead of
>>>>>>>>always extend 1 legal move. Does it
>>>>>>>>blow up?
>>>>>>
>>>>>>
>>>>>>>  I guess you read it in Ed's programming page about Rebel. He does that in
>>>>>>>qsearch, and regarding checking moves generation.
>>>>>>>  I tried his idea in my private program and it didn't work for me. It generated
>>>>>>>too many nodes, but I probably did something wrong.
>>>>>>
>>>>>>Checks in QS works provided you hash in QS. With exploding checks hash
>>>>>>move-ordering is crucial.
>>>>>>
>>>>>>My best,
>>>>>>
>>>>>>Ed
>>>>
>>>>>  I thought of this too. The problem I couldn't solve (properly) was about
>>>>>draft. When I tried hashing qsearch in Averno (no checks in qsearch), I simply
>>>>>stored those positions with draft = 0, as they're all equivalent.
>>>>>  But when I tried in my other program (with checks according to your schema) I
>>>>>couldn't use 0 as draft as remaining check-depth was important in order to give
>>>>>a cutoff. I had two options: use draft 0 and only to store a move (no cutoff) or
>>>>>create a different hash table only for qsearch with checks. After check-depth
>>>>>was zero, I used again the main transposition table with draft = 0.
>>>>>  I tried the latter and didn't work well. I should probably try using it only
>>>>>for move ordering, with draft = 0.
>>>>
>>>>In my baby the draft in QS simply becomes negative, so -1, -2 etc. You can't do
>>>>the same?
>>>>
>>>>Ed
>>
>>>You should avoid letting it go negative.  Is there any difference from a hit two
>>>moves deep into the q-search vs 4 moves deep?  IE can you consider moves at
>>>ply=2 that you can't consider at ply=4 in the q-search?  If not, why restrict it
>>>so that ply=2 probe can't use a position stored at ply=4 elsewhere?
>>
>>Because the mate-value differs. I want my QS to return correct mate-in-x values.
>>
>>My best,
>>
>>Ed
>
>Hi Ed,

Hi Gerd,


>isn't mate-score only dependent from distance to root (ply-index), but not from
>draft (depth)?

Correct.


>Therefore clipping depth to zero should not affect mate scores, or?

In my engine it does affect, take this famous position:

[d]5n2/B3K3/2p2Np1/4k3/7P/3bN1P1/2Prn1P1/1q6 w - -

When I try draft=0 in QS then the mate-in-30 isn't found at all, not after 17-18
plies. When I use my way of doing the mate is found on ply-1, meaning that all
is found in QS.



>Anyway i store negative depth too (conditionally see below), it seems to
>work slighly better for me than clipping draft to zero.
>
>I use a two table approach, a huge transposition table with 8 slots per
>hashindex and depth prefered replacement, only used if depth > MINDEPTH, and a
>small allways replace table for depth >= MINDEPTH and conditionally for depth <
>MINDEPTH.

On my end:

. 4 slots
. large always replace table in case 4 slots doesn't suffice.
. QS nodes always go directly into the always replace table.
. draft replacement scheme (not depth).


>While probing, MINDEPTH is zero.
>While storing, MINDEPTH is zero for EXACT scores and LOWER_BOUNDS,
>but MINDEPTH is one for UPPER_BOUNDS with no best move.

I see.

I don't store moves with no-best-move, spares the data cache. I have tried
5-6-7-8 slots in the past but there was no gain. There were less nodes but
(slightly) higher solution times because of the extensive use of the data cache.



>The same trigger (some forced flag(s) set in the path from root) which enables
>checks in my quiescence search, is used as a condition to store/probe the small
>allways replace table.

I think I will keep my own system, besides the problem with mate positions I
noticed very little improvement with the draft=0 system in QS, less than 1%.

Thanks Gerd,

Ed



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.