Author: Robert Hyatt
Date: 14:13:59 09/14/04
Go up one level in this thread
On September 14, 2004 at 12:35:50, Ed Schröder wrote:
>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.
Do you allow _exact_ hash matches with a mate score? If so, this doesn't cure
the problem in both directions. You can graft a deep mate or a shallow mate to
the end of a search line.
>
>
>
>>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?
Now take it the other way and it breaks. Make the mate _deeper_ rather than
shallower...
>
>
>
>>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.