Author: Michael Henderson
Date: 10:51:42 09/13/04
Go up one level in this thread
On September 13, 2004 at 11:31:44, Ed Schröder wrote:
>On September 13, 2004 at 10:16:58, Robert Hyatt 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
>
>
>>Mate scores should _always_ be adjusted anyway. IE adjust from
>>mate-in-N-from-root to mate-in-N-from-here before storing, and adjust back on a
>>hit, just like you do in the normal search...
>
>I have seen this issue coming up again and again however I never experienced any
>problem with mate-values in regard to the hash table. Every mate-value is ply
>driven (see below) to distinguish its length.
>
>static int mate_value [ ] { 0, 100000, 99999, 99998, 99997 .... };
>
>These values go right into the HT without any adjustment.
>
>Ed
Ok I just wanted to give my own simple scenario even though I know Hyatt already
answered your question :)
Two long (20 ply) variations from the root returned some kind of mate score. At
ply 3 in both of those variations, you got EXACT hash hits with mate scores for
both of those variations. From your method I guess you would return MATE - 3
for both of them? But just storing MATE in table loses the actual depth to the
mate. So the two variations could have different depth to mate. If I am wrong
please excuse me!
Michael
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.