Author: Robert Hyatt
Date: 10:20:07 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
Houston, you have a problem. :)
What do you do here:
search A, B, C, D, E, F, G, H, I, J, K and find that at K you have no legal
moves and you are in check. Hence you are mated. The mate score we all use
here is X - ply where X is some big number (I use 32768 myself). So here the
mate score is X-11. When you back up to one of the earlier positions and store
X-11 you just primed the pump for a wrong mate announcement. For example you
store (in my case) 32768-11 = 32757 at position F.
Now you search another path that goes like this:
A1, B1, C1, D1, E1, F1, G1, H1, I1, J1, K1, F
at position F you retrieve the mate score and it is dead wrong. Yes there is a
mate below position F, but it happens 5 plies below position F. But you just
got a hash hit and returned the 32757 score which says "mate in 11 plies from
the root" but there is no such mate here.
In Crafty I store the correct mate score, which is "this is a mate in N plies
from _this_ position, not from the root."
In the above, at position F, I store "mate in 5 plies". In the second path, I
find mate in 5 plies in the hash table at position F, but then I add the number
of plies from the root to F to get the correct mate score.
If you don't adjust them there is no way you can return the right mate score
back to the root. You can return _A_ mate score, if that is good enough, but it
is dangerous and can lead to unexpected draws...
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.