KingCapture Engines - logical NullMove problem ?

[Daniel Mehrmann]

Hello,

my engine is a "KingCapture" engine. So i only know that it's mate if i can capture the king. I found the following logical problem in my engine:

If white is mate and moved with the king normaly i expect the return value "KingCapture". This works fine, but its possible on the next node that white could do a "NullMove" and go out of the Mate und that would be a cutoff.

The only solution, that i found, is to do no NullMove if the last node was "incheck". We must do that on all nodes, no matter if all, cut, or pv.

Better ideas ?

Best,
Daniel

[Uri Blass]

This is the way that all the engines work
There is no point in doing null move when the king is under threat
and the question if your program is a king capture engine is not relevant because it is obviousthat the when you threat the opponent king you have a threat.

I also do not think that a king capture engine is a good idea and I think that it is better to detect mate by evaluation.

Not detecting mate by evaluation means that you may need one more ply to see mate and I do not think that it is a good idea.

Uri

[H.G.Muller]

The null-move symbolizes all moves that you don't want to consider explicitly because they're not likely to do anything important. When in check, such moves are illegal, and thus the null-move should be considered illegal as well.

My engine employs a mixture between king-capture and mate-checking:
when it is in check it is only allowed to consider (and indeed must do so irrespective of ply depth) those moves that potentially save the king (moving it away or obstructing or capturing the attacker, if only one). I have to do a full move-generation on that ply anyway to find obstructing moves, for which I know no shortcut selective generation. This could be considered mate checking.

Yet king-captures do occur: It does test if the piece just moved by the opponent threatens its king (which is a very specific question that can be cheaply answered), but when it moves his own king it has little idea if it blunders into trouble. Trying the move is actually a very cheap way to find this out: the opponent will always start his turn by selectively trying to capture the piece that last moved with all pieces worth less or equal (so for a king: with all pieces), so if a king capture is possible it is found immediately before any responses are actually tried, and the king move is not counted as legal. (Capturing the rook after castling is also considerd (e.p.) king-capture, to intercept illegal castlings).

[Gerd Isenberg]

This is the way that all the engines work
There is no point in doing null move when the king is under threat
and the question if your program is a king capture engine is not relevant because it is obviousthat the when you threat the opponent king you have a threat.

I also do not think that a king capture engine is a good idea and I think that it is better to detect mate by evaluation.
Uri

Hi Uri,

do you mean evaluation or inCheck evasion?
Thus by generating an empty list of legal moves?

If one generates pseudo legal moves in a typical inCheck evasion move generator, it is likely that invalid moves may be introduced:

[diag]4r3/6k1/7b/8/2b1R3/5P2/1qB1KP2/2QNB3 w - -
[/diag]
Here engines may generate Kf1, Rxc4 and Bd3 and therefor must make the moves to determine they are all invalid.

Not detecting mate by evaluation means that you may need one more ply to see mate and I do not think that it is a good idea.
Uri

Whether this is done by ordinary and probably fast make/unmakeMove and an "opponent King" in check or already during a legal move generation is pragmatically the same... except - and may be that is what you mean with mate detection by evaluation - that one may prepare and use information about pinned pieces already in evaluation.

What i understand by mate detection in eval is finding a mate in one move statically.

Gerd

[Gerd Isenberg]

Hello,

my engine is a "KingCapture" engine. So i only know that it's mate if i can capture the king.

Hi Daniel,

i don't get exactly that what you mean by "KingCapture" engine !?
Do you mean pseudo legal move generation and detecting ilegal moves by capturing the king?

I found the following logical problem in my engine:
If white is mate and moved with the king normaly i expect the return value "KingCapture". This works fine, but its possible on the next node that white could do a "NullMove" and go out of the Mate und that would be a cutoff.

The only solution, that i found, is to do no NullMove if the last node was "incheck". We must do that on all nodes, no matter if all, cut, or pv.

Better ideas ?

Best,
Daniel

Of course nullmove in check makes no sense.
Do you really have no inCheck function?

Gerd

[Uri Blass]

This is the way that all the engines work
There is no point in doing null move when the king is under threat
and the question if your program is a king capture engine is not relevant because it is obviousthat the when you threat the opponent king you have a threat.

I also do not think that a king capture engine is a good idea and I think that it is better to detect mate by evaluation.
Uri

Hi Uri,

do you mean evaluation or inCheck evasion?

Gerd

I mean evaluation
I simply generate list of legal moves when the king is under threat
and return the evaluation and if the king is not under threat the evaluation already counted the number of legal moves and put it in eval_dat[ply].mobility.

the function finished tell me if the game was finished and I call it after every evaluation.

int finished()
{
if (kingincheck>0)
{
gen();
if (first_move[ply+1]>first_move[ply])
return 0;
else
return 1;
}
else
{
if (eval_dat[ply].mobility>0)
return 0;
else
return 1;
}
return 1;
}

Thus by generating an empty list of legal moves?

If one generates pseudo legal moves in a typical inCheck evasion move generator, it is likely that invalid moves may be introduced:

[diag]4r3/6k1/7b/8/2b1R3/5P2/1qB1KP2/2QNB3 w - -
[/diag]
Here engines may generate Kf1, Rxc4 and Bd3 and therefor must make the moves to determine they are all invalid.

Movei does not generate these moves
The move generator detects that f1 is in the direction of the bishop threat so it does not generate that move
It detect that the rook and the bishop are pinned so it does not need to generate bishop moves and does not need to generate rook moves except move in the pin direction.

I do not claim that it is a good idea but I do not like the idea of pseudo legal move generator.

Not detecting mate by evaluation means that you may need one more ply to see mate and I do not think that it is a good idea.
Uri

Whether this is done by ordinary and probably fast make/unmakeMove and an "opponent King" in check or already during a legal move generation is pragmatically the same... except - and may be that is what you mean with mate detection by evaluation - that one may prepare and use information about pinned pieces already in evaluation.

What i understand by mate detection in eval is finding a mate in one move statically.

Gerd

I update information about pinned pieces to the king in my makemove and not during evaluation.

I think that it is better to delay it to evaluation time because there are cases that I prune without evaluating after making a move.

originally I needed to update information about pinned pieces during makemove because my makemove also calculated the evaluation but now it no more doing it so I do not need it.

Uri

[Gerd Isenberg]

I mean evaluation
I simply generate list of legal moves when the king is under threat
and return the evaluation and if the king is not under threat the evaluation already counted the number of legal moves and put it in eval_dat[ply].mobility.

the function finished tell me if the game was finished and I call it after every evaluation.

I see - may be a matter of taste or programming "style" - with booleans i would write your routine a bit more compact - even if the generated assembly is the same, but sometimes it is a hint for the compiler to avoid branches. If you don't like it or if it is more difficult to read for you - don't bother

Code: Select all

int finished()
{
  if (kingincheck>0)
  {
     gen();
     return first_move[ply+1] <= first_move[ply];
  }
  return  eval_dat[ply].mobility == 0;
}


I update information about pinned pieces to the king in my makemove and not during evaluation.

I think that it is better to delay it to evaluation time because there are cases that I prune without evaluating after making a move.

originally I needed to update information about pinned pieces during makemove because my makemove also calculated the evaluation but now it no more doing it so I do not need it.
Uri

I also do legal move generation. Since i cache evaluation in TT as well in a separate table, i have some flags per node which tell me whether pinned pieces per side are already generated or not.

Gerd

[Daniel Mehrmann]

Hi Gerd,

Hi Daniel,

i don't get exactly that what you mean by "KingCapture" engine !?
Do you mean pseudo legal move generation and detecting ilegal moves by capturing the king?

This is exactly what i do Gerd. I have a inCheck() function of course, but i generate pseudo legal moves, where is King could go out of check (mate).

Best,
Daniel

Btw KingCapture engines must not be bad than Uri wrote. I'm using for example allso singular extensions, where maybe some guys thinking now how is this possible in that case without many costs

[Gerd Isenberg]

Hi Gerd,

Hi Daniel,

i don't get exactly that what you mean by "KingCapture" engine !?
Do you mean pseudo legal move generation and detecting ilegal moves by capturing the king?

This is exactly what i do Gerd. I have a inCheck() function of course, but i generate pseudo legal moves, where is King could go out of check (mate).

Best,
Daniel

Btw KingCapture engines must not be bad than Uri wrote. I'm using for example allso singular extensions, where maybe some guys thinking now how is this possible in that case without many costs

Of course pseudo legal move generation is very common. Ignoring pins is simply faster in most cases. Feel free to elaborate about your SE implementation.

Gerd