Author: Ed Schröder
Date: 09:35:50 09/14/04
Go up one level in this thread
On September 13, 2004 at 13:20:07, Robert Hyatt wrote:
>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. :)
No, Houston is fine :)
It's just that the problem you so eloquently described below is handled
elsewhere in my search, that is, when going one ply deeper in the search I set a
mimimum (mate) value of that ply in a separate stack.
>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
In my system the mate score of F is not accepted because it can't go lower than
the minimum value of the ply. So the best score so far for that ply remains the
minimum value of that ply.
Simple huh?
>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...
Never experienced any problem.
I bet my system is 0.001% faster :)
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.