Author: Robert Hyatt
Date: 11:55:11 10/28/98
Go up one level in this thread
On October 28, 1998 at 10:37:22, James Robertson wrote: >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 Both. :) In the normal (full-width) search I check for legality before recursing to the next ply. In the q-search, I don't, because it is actually faster there to wait and capture the king at the next ply, on those not-so-common illegal captures, rather than doing the in-check test. And since I don't do null move or other funny stuff in the q-search, it isn't a problem...
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.