Author: James Robertson
Date: 07:37:22 10/28/98
Go up one level in this thread
On October 28, 1998 at 09:09:09, Robert Hyatt wrote: >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... Which method does Crafty use? Generating moves and catching checks on the next ply, or having a check test before the move is tried? James
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.