Author: Dieter Buerssner
Date: 18:05:22 10/29/01
Go up one level in this thread
On October 29, 2001 at 05:37:15, Ed Schröder wrote: >On October 29, 2001 at 01:30:12, Dieter Buerssner wrote: >> 7k/6R1/6R1/1r5P/6K1/8/8/8 b - - 0 55 >> >Nice position... I tried to find the longest (is it?) defence: > >1..Rg5 2.Kf4 Rf5 3.Ke4 Re5 4.Kd4 Rd5 5.Kc4 Rc5 6.Kb4 Rb5 7.Kc3 Rc5 >8.Kd3 Rd5 9.Ke3 Re5 10.Kf3 Rf5 11.Kg3 Rg5 12.Kf2 Rf5 13.Ke2 Re5 14.Kd2 >Rd5 15.Kc2 Rc5 16.Kb2 Rb5 17.Kc1 Rc5 18.Kd1 Rd5 19.Ke1 Re5 20.Kf1 Rf5 >21.Kg2 Rg5 22.Kh3 Rg3 23.Kh2 Rg2 24.Kh1 Rg1 25.Kh2 Rg2 -> repetition I am not sure. I would think, the king can go at least 2 times to a. On the other side, for programs with TBs, the K can never go to h, because Rxh5 will show a draw score immediately. >Typical position for the King I would say. > >But how can you evaluate (detect) stalemate in QS? > >Looks pretty dangerous to me because of its selective nature and >you can't just say score=0.00 in case no more captures or checks >are generated. So what is the big secret? Code, that is rather slow for an inner loop. So, I mean a reliable stalemate detection, no guessing. No secret at all. But of course, just generating captures to decide about stalemate can not work at all - IMO. Regards, Dieter
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.