Author: Ricardo Gibert
Date: 16:18:10 11/16/00
Go up one level in this thread
On November 16, 2000 at 17:24:37, Lenard Spencer wrote: >On November 16, 2000 at 04:25:53, Ricardo Gibert wrote: > >>On November 16, 2000 at 02:51:47, Tony Werten wrote: >> >>>On November 15, 2000 at 20:40:16, Lenard Spencer wrote: >>> >>>>This question may probably be best answered by the problemists, but if what I'm >>>>thinking is correct, it may be possible to make looking for double checks go a >>>>lot faster than the brute force approach of looking all over the board for more >>>>than one checker. >>> >>>The way I use it: >>>first, can the piece just moved attack the king (lookup table)? If so get the >>>direction in which it needs to travel (same lookup table) and check if there are >>>any other pieces blocking. >>> >>>second, can a rook or bishop attack the king from the fromsquare of the moved >>>piece. If so get the direction, then travel from the king in the direction of >>>the fromsquare until you go off the board (no discoverd check) or bump into a >>>piece (if piece=rook,bishop,queen then it's a discovered check) >>> >>>if ( first and second) then doublecheck:=true; >>> >>>Tony >> >>How about this position: >> >>[D]8/8/7k/6pP/8/4B3/7R/7K w - g6 >> >>The move 1.hxg6 is double check, but it is not clear to me how your algorithm >>catches this. >> > >In this example, the pawn move delivers a double check, but the pawn itself is >not a checking piece. But it does serve to illustrate just how tricky it can >be. Yes, that was the point of my post. It is unusual, because it is a "double discovered check" to put it more precisely. The loss of the Black pawn discovers a check from the Bishop and the capture by the White pawn discovers a check from the Rook. There is a similar "joker" concerning pins too, which a naive algorithm may miss.
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.