Author: Robert Hyatt
Date: 06:09:09 10/28/98
Go up one level in this thread
On October 28, 1998 at 08:50:06, Peter Fendrich wrote: >In the Search, when a move is generated and made, I always call the KingInCheck >routine to find out if the side who moved is in check. If so the position is >illegal and a new move is generated. > >Sometimes it is proposed to skip the KingInCheck test and let the move >generator, in the next ply, capture the king. In that case stop that node and >return error. The idea is to gain performance by not calling the KnigInCheck at >all and that the illegal positions are so uncommon that it's worth the extra >overhead the few times it happens. > >I never liked that idea but started to think about it anyway... >I think it's somewhat unnatural to have possibly illegal positions around and it >makes the program more complex. Some thoughts: I do this in the q-search, but not in the normal search. There I do just as you do and make sure I don't leave the king in check after making a move. I do this to avoid several problems: 1. tablebase probes depend on legal positions being probed. So the test is required there for sure. 2. null-move searches after an illegal move can cause problems. You can try to detect this in other ways, but you certainly don't want to fail high if the position is illegal, as that might convince you that you can evade mate there. > >1) >When the NullMove starts at next ply, I certainly don't want to have illegal >positions around. >By making a call to KingInCheck before the NullMove the whole idea with delaying >the check is spoiled so that's not a solution. correct.. >Another way is to generate the first move in order to see if the position is >legal, before the NullMove is started. A capture of the King is supposed to be >the first thing to find and in that case return error, never letting the >NullMove start. probably just as expensive as the in check test, or maybe even more-so... > >2) >There ar other things that is done before the 'real' search is started, like >hash table look up, repetition check, end game tables and more. What are the >side effects? > >3) >What will happen in the Quiescence when the Evaluate is called in the beginning? >There might be an illegal position to Evaluate. Maybe not so dangerous but you >have to think about it when you do your evaluate coding. not a problem, because you *still* will end up generating captures, and when you capture a king, you simply return "error" to the previous level and never use that illegal evaluation... there may be a few "glitches" to work out of this, of course... > >In short it's too complex for my taste (I don't have to invent bugs - I 'm happy >with the ones I have!) and I don't see any real performance gains. At least not >for my program. At least not in theory. > >Have you measured it and how do you handle situations like those above? > >//Peter I came to the same conclusion you did...
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.