Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: hash table & draw detection

Author: Michael Williams

Date: 19:25:28 05/03/02

Go up one level in this thread


On May 02, 2002 at 11:00:08, Will Singleton wrote:

>On May 02, 2002 at 06:00:51, Ricardo Gibert wrote:
>
>>On May 02, 2002 at 01:54:29, Will Singleton wrote:
>>
>>>On May 02, 2002 at 00:02:53, Robert Hyatt wrote:
>>>
>>>>On May 01, 2002 at 21:53:01, Will Singleton wrote:
>>>>
>>>>>On May 01, 2002 at 11:41:54, Arwin Smit wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I programmed a hash table for my chess engine. It seems to be faster
>>>>>>and stronger now, but as far as I know the disadvantage of using a
>>>>>>hashtable is that the engine will not always find the best solution
>>>>>>anymore. And this is caused by not being able to see a 3-fold repetition
>>>>>>draw anymore in some cases. A position may be in the hash table and
>>>>>>returning a non-draw score, but it was reached in a different part of the
>>>>>>search tree by repetition of positions.
>>>>>>
>>>>>>This worries me a bit since this is the first time I made a change to my
>>>>>>engine causing it to be "non-perfect".
>>>>>>Is the advantage bigger than the disadvantage?
>>>>>>What is the best way to test which version is better anyway? Just let it
>>>>>>play a lot of games against eachother?
>>>>>>
>>>>>>Arwin
>>>>>
>>>>>It's possible you can fix this by 1) not storing draw scores in the hash table,
>>>>>and 2) testing for repetition prior to probing the hash (if you don't use the
>>>>>main hash for your rep detection).
>>>>
>>>>
>>>>
>>>>There is really no way to close all the holes.  It is possible that the
>>>>path from the current position to the tip, which is found by a hash hit,
>>>>repeats a position between the current position and the root.  But it is
>>>>impossible to know this without storing the complete path in a hash entry.
>>>>
>>>>Not storing draw scores is (IMHO) a bad idea.  A draw score is as legitimate
>>>>as any other score.  Not storing them to avoid one problem simply creates
>>>>another on the other side...  And it still doesn't solve the first problem
>>>>I gave, which means errors are going to occur, period...
>>>>
>>>>I simply ignore them...
>>>>
>>>>
>>>
>>>Hmmm... I don't know about that.  You say that a position occurring between the
>>>current position to the tip may contain a repetition of a position that occurred
>>>between the current position and the root, and that the score of the current
>>>position wouldn't reflect the draw without storing draws in the hash.  My point
>>>was that, if you don't hash draw scores, the current position would not appear
>>>in the hash, and the draw would have to be found by the normal search.  Which
>>>seems to work fine in my prog.
>>
>>He not talking about false draw scores, he is talking about missing a draw by
>>repetition.
>>
>
>?  So am I.
>
>>>
>>>Let's take another example. Suppose you find a draw in a search, at ply 7 (draft
>>>0), which gets stored as exact in the hash.  Now you and the opponent move, and
>>>in the next search, you find that draw score at ply 5 (draft 0).  But it turns
>>>out that the original draw score was from a two-fold repetition in the search,
>>>and that two-fold rep doesn't exist in the current search.  Hence, the draw
>>>score in the hash is incorrect.
>>
>>The draw score is correct, because a forced repetition is anticipated. The draw
>>score would not be there if it was avoidable. It does not matter that the
>>current line does not contain a repetition...yet.
>>
>
>This seems a bit "theoretical".  If you want to give an example to explain your
>point, I'd appreciate it.  But it's clear that not storing draw scores has
>little practical downside, if any.

Whether this addresses your request or not, it is interesting:

1934 USCF vs. 2258 USCF

1. d4 d5 2. Nf3 Nf6 3. Bf4 e6 4. e3 Be7 5. Bd3 Nbd7 6. c3 c5 7. Nbd2 Nh5 8. Bg3
Nxg3 9. hxg3 h6
10. Ne5 Nxe5 11. dxe5 Qc7 12. f4 Bd7 13. Qg4 Bf8 14. Nf3 O-O-O 15. Ng5 Be8 16.
Nh7 Qe7 17. Kf2 Rxh7
18. Bxh7 g6 19. Rhd1 Kb8 20. Qh4 Rd7 21. Qf6 Qxf6 22. exf6 Kc7 23. Rd2 b6 24.
Rad1 a6 25. Bg8 Bd6
26. Kf3 Rd8 27. g4 c4 28. Rh1 Bf8 29. g5 hxg5 30. fxg5 Bc5 31. Rh7 Rd7 32. Ke2
e5 33. Rh8 Rd8
34. Rh7 Rd7 35. b4 cxb3 36. axb3 a5 37. e4 d4 38. cxd4 Bxd4 39. Rxd4 exd4 40. e5
Rd5 41. e6 Re5+
42. Kd3 Rxe6 43. Bxf7 Bxf7 44. Rxf7+ Kd8 45. Rg7 Ke8 46. Rxg6 Re3+ 47. Kxd4 Rxb3
48. Rg8+ Kf7
49. Rg7+ Kf8 50. Ke4 Rg3 51. Kf5 Rxg2 52. Kg6 Re2 53. Rb7 Re6 54. Rb8+ Re8 55.
Rxe8+ Kxe8
56. Kg7 1-0

Fritz 7 in the position below gives at the "19th ply" its best line, starting
with 37.Ra2 containing a three-fold repetition of the position in deep analysis
mode.  I find both positions interesting.  Here, 37.e4 is easy for a 1900 player
to prove a win.

[D] 4b1B1/2kr1p1R/1p3Pp1/p1bpp1P1/8/1PP1P3/3RK1P1/8 w - - 0 36

In the diagram below, Fritz 7 gives large positive scores (1.47) for White
while displaying 3-times repetition at plies 17 to 20 for 39.Rc2 and 39.g4
during deep position analysis, whereas Shredder6 does not.

Incidentally, Fritz6 takes until the "23 ply" to find 39.Rxd4, and Fritz 7
doesn't find it after "22 plies" though I stopped the analysis

[D] 4b1B1/2kr1p1R/1p3Pp1/p3p1P1/3bP3/1P6/3RK1P1/8 w - - 0 38


>>>
>>>That was part of my thinking in not storing the draw scores.  In any case, the
>>>search will find any draws without the need for storing them.
>>>
>>>Will



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.