Author: Robert Hyatt
Date: 18:49:21 12/27/98
Go up one level in this thread
On December 27, 1998 at 14:59:26, Roberto Waldteufel wrote: > >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 In crafty, no. I carefully "fudge" the mate score when it is stored, so that it is always "mate in N from the current position, not from the root." As a result, I don't see this type of problem as it would be serious otherwise, since it is imperative to play a mate in n-1 rather than a mate in n when it is possible.
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.