Author: Roberto Waldteufel
Date: 11:59:26 12/27/98
Go up one level in this thread
On December 27, 1998 at 14:33:39, Richard A. Fowell (fowell@netcom.com) wrote: >On December 27, 1998 at 10:34:40, Robert Hyatt wrote: > >>On December 26, 1998 at 18:51:46, Richard A. Fowell (fowell@netcom.com) wrote: >> >>>Do hash tables confuse your matefinding routines? >>> >>>I tried this mate in 7: >>>8/krK5/p7/P7/6P1/8/7Q/8 w - - >>> >>>on two different chess programs, by two different authors, >>>and both reported erroneously short mates when their hash tables were on. >>> >>>With hash tables off, the correct solution was given by both programs. >>> >>>In both cases, the programs were using special-purpose matefinding logic >>>that had no known problems before. >>> >>>Can anyone shed any light on this? >>> >>>Since this problem showed up in the only two programs I tested >>>for this, it seems like it may be a widespread issue. >>> >>>When I use Sigma Chess 4.01 Lite with hash off, >>>using the "mate in 7" setting, I get the right answer: >>> >>>Hash off (Mate in 7) - Kc7-c8, Mate in 7, 948.7 seconds >>>Kc7-c8 Rb7-b3 >>>Qh2-h7 Ka7-a8 >>>Qh7-e4 Ka8-a7 >>>Qe4-d4 Ka7-a8 >>>Qd4-d5 Ka8-a7 >>>Qd5xb3 Ka7-a8 >>>Qb3-b7 >>> >>>When I enable hash, Sigma Chess (erroneously) reports mate in 6 - >>>with pretty much a different PV for every hash table setting I tried. >>>The key move is right, and the time is much shorter >>>(2.4 sec, 6.9 sec, 8.0 sec, 11.1 sec, 12.5 sec, 32.6 sec in the cases I tried), >>>but the evaluation is wrong. >>> >>>When I use MacChess 5.0 EN, at level "mate in 7", (which uses hash tables) >>>it reports a mate in 4. >>>When I use MacChess 4.0 at level "mate in 7", (which does not use hash tables) >>>it reports the correct mate in 7, e.g.: >>> >>>MacChess 4.0 EN >>> >>>1. Kc8 Rb3 >>>2. Qc7+ Ka8 >>>3. Qc6+ Ka7 >>>4. Qd7+ Ka8 >>>5. Qd5+ Ka7 >>>6. Qxb3 Ka8 >>>7. Qb7# >>> >>>So ... what's going on, here? >>> >>>Richard A. Fowell (fowell@netcom.com) >> >>This has to be a bug. Hash tables can't find a "shorter mate" than actually >>exists on the board, unless there is a bug. Hash tables can let a shallow >>search see "much deeper" than you would expect (position fine#70 is the classic >>example that programs solve at a much shallower depth than is actually >>possible). > >That was the conclusion of one of the two authors (the other hasn't looked >into it much yet). The thing that struck me about this is that I'm seeing >this behaviour in two different programs, by two different authors, who >don't collaborate with each other. So, I'm thinking that this bug may >be easy to introduce, and that other programs have it. Further, that >other programmers on this board may have run into it before, and can >tell us what the flaw is > >Richard A. Fowell (fowell@netcom.com) I may well be completely wrong, but it might be that the hash tables have a single score for "giving mate" and another single score for "being mated". This could conceivably cause the sort of behaviour you describe, because the "draft" of the hash score will not be taken into account, although the hashed move should be good unless it should happen to be erroneous due to repetition or 50-move rule draws. That would explain why the key move was correct although the number of moves to mate would be shorter than it should be. Just a suspicion - maybe there is another explanation? Best wishes, Roberto
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.