Author: Richard A. Fowell (fowell@netcom.com)
Date: 11:33:39 12/27/98
Go up one level in this thread
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)
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.