in_check

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Daniel Shawul
Posts: 4185
Joined: Tue Mar 14, 2006 11:34 am
Location: Ethiopia

in_check

Post by Daniel Shawul »

For orthodox chess this method is relatively cheaper and hence is taken advantage of to weed out illegal moves, do a check extension etc..
But for other fairy piece games where a piece can move in a weird way, it becomes very difficult to do and very bulky. For example long-leapers jump over pieces, chameleon acts like the piece it is in contact with...
So the in_check routine I have now almost does a whole move generation to test if a king is in-check or not. There aren't too many tricks you can do to alleviate this problem specially when you are trying to write a 'general' engine. So I discarded that routine and got a speed bump of 4X i repeat 4X :)
I let the king be captured like TSCP does in qsearch and score the position as a loss. Only downside I observed is it is dumb in detecting mates and stalemates. Is curing this problem with in_check worth it? I don't know.
I am thinking of a way to detect a king was in check after it got captured and trace back up a ply or so, to do the extension. But this is not accurate and I don't know if it will improve this problem.

Also I have found that generating evasions in qsearch is a loss atleast for my engine. It wins by 70-30 against the one which does correct evasion generation. The implementation is a bit different from TSCP's. I do not null move in qsearch (stand pat) when being in check. Then I try only captures, so if a capture happens to defend well against the check, all is well and eval is accurate. Otherwise it is a loss since we didn't do the stand pat. This seems to work very well in most cases and I would say it made it more tactically aware regarding king attacks(no king safety in eval) , if I was not biased :) It really is good in some tactical tests. It goes bad when I turn accurate move generation. I may be chasing a ghost here but results seem to support my theory.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: in_check

Post by Evert »

Daniel Shawul wrote:For orthodox chess this method is relatively cheaper and hence is taken advantage of to weed out illegal moves, do a check extension etc..
But for other fairy piece games where a piece can move in a weird way, it becomes very difficult to do and very bulky. For example long-leapers jump over pieces, chameleon acts like the piece it is in contact with...
So the in_check routine I have now almost does a whole move generation to test if a king is in-check or not. There aren't too many tricks you can do to alleviate this problem specially when you are trying to write a 'general' engine. So I discarded that routine and got a speed bump of 4X i repeat 4X :)
That's a pretty big jump there!
I've given a little bit of thought about Ultima, and it seems very hard to write a general purpose routine like this. For in-check it isn't completely horrible since you can do a very restricted search from the king's position, but it's still hard to catch in a general framework. Doing a general "attacked squares" is very difficult, especially for the chamaeleon. The withdrawer can be a bit nasty too.
I let the king be captured like TSCP does in qsearch and score the position as a loss. Only downside I observed is it is dumb in detecting mates and stalemates. Is curing this problem with in_check worth it? I don't know.
I am thinking of a way to detect a king was in check after it got captured and trace back up a ply or so, to do the extension. But this is not accurate and I don't know if it will improve this problem.
I would probably make the in_check test optional, so variants that benefit from it do and variants where it's too complicated to do skip it and do what you describe here.
Also I have found that generating evasions in qsearch is a loss atleast for my engine. It wins by 70-30 against the one which does correct evasion generation. The implementation is a bit different from TSCP's. I do not null move in qsearch (stand pat) when being in check. Then I try only captures, so if a capture happens to defend well against the check, all is well and eval is accurate. Otherwise it is a loss since we didn't do the stand pat. This seems to work very well in most cases and I would say it made it more tactically aware regarding king attacks(no king safety in eval) , if I was not biased :) It really is good in some tactical tests. It goes bad when I turn accurate move generation. I may be chasing a ghost here but results seem to support my theory.
I guess it also depends on how good your check-evasion move generator is. If it generates many moves that are illegal, then it may well fairly expensive.
Looking at my code, it seems that I do take the stand-pat cut-off in check though, and I also update alpha. I'll check what effect that has.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: in_check

Post by Evert »

Evert wrote: Looking at my code, it seems that I do take the stand-pat cut-off in check though, and I also update alpha. I'll check what effect that has.
Well, not taking the cut-off in check seems to be better, which is not really surprising. I've only done a few quick tests though...
Daniel Shawul
Posts: 4185
Joined: Tue Mar 14, 2006 11:34 am
Location: Ethiopia

Re: in_check

Post by Daniel Shawul »

Another game I did which required special attacks routine is Jetan. In that game a piece can move from a from square to a to square while changing direction during flight ! Nightrider is easy because its direction is fixed from the start... So to check if a piece is blocked you have to make sure all the possible paths are blocked. I am sure there are many other games where you would have to write a special attacks. That made me think writing the pattern once for move generation is good enough. Attacks would become more and more similar to move_generate, so why bother ? And the hints I got from my tests are in support of removal too.
I guess it also depends on how good your check-evasion move generator is. If it generates many moves that are illegal, then it may well fairly expensive.
Looking at my code, it seems that I do take the stand-pat cut-off in check though, and I also update alpha. I'll check what effect that has.
Surprisingly it is plain old pseudo-legal move generator, which is as slow as the captures generator being piece-list . No speed penalty. I suspect it is just the way it fills some void in king-safety eval. The latter one takes many risks classifying some safe positions as lost when there is no capture move to refute the check. I tried again and again past two months with no success :?
User avatar
hgm
Posts: 27808
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: in_check

Post by hgm »

In micro-Max / Fairy-Max I start doing null move (when not in QS), and if that gets an illegal-move score (the negative of a King-capture score) I know it as in check. The real moves are then searched with an extension. This is completely general, but, like you say, slow.

In Spartacus I do 'retrograde' capture generation, so I start generating captures to the opponent King square. (And, in case of a castling, to the skipped square.) If the move stack is not empty after that, I immediately return the King-capture score. (Unless I had a spare King.)

It does not seem more expensive to test for captures of the King in a 0x88-spirit than it is in Chess. It might be far more difficult to test if a piece is pinne, though. In Joker I use shortcuts in move generation by suppressing generation of moves of pinned pieces. But that is not general enough, and already made it difficult to convert it to Kightmate. (Pinned Knights have no moves, but pinned Commoners usually do.)