persistent stalemate threat

[lucasart]

More stupid thoughts. Do you have a routine for detecting stalemate, or is it done in the search? If the former then you could recycle the code, if the latter you could bring the score closer to zero.

I detect stalemates in the search, but not in the quiescent search.
As explained above, I will test a stalemate detection in the qsearch, by coding a sufficient but not necessary test for stalemate (king can't move + no mobile pawn + no pieces).

Also, could you *please* be uci compatible and use 'score mate x' rather than 'score cp (hugenumber-x)'?

I've always been too lazy to do it, but if you insist
Also to be even more UCI compliant, I need to report the lowerbound and upperbound when an aspiration search fails high/low.

[ZirconiumX]

Well having Sigma report 'mate in / moves!' is a bit embarrasing, wouldn't you say?

Matthew:out

[lucasart]

Well having Sigma report 'mate in / moves!' is a bit embarrasing, wouldn't you say?

Matthew:out

Why should I be embarassed about the bugs of sigma chess ? Besides, I don't use it, because I don't use a Mac in the first place

[lucasart]

More stupid thoughts. Do you have a routine for detecting stalemate, or is it done in the search? If the former then you could recycle the code, if the latter you could bring the score closer to zero.

I detect stalemates in the search, but not in the quiescent search.
As explained above, I will test a stalemate detection in the qsearch, by coding a sufficient but not necessary test for stalemate (king can't move + no mobile pawn + no pieces).

Another idea I had was to detect stalemates in the eval directly. However it violates the most fundamental postulat of the negamax algorithm: score symmetry [for all position P, score(P, White to play) + score(P, Black to play) = 0]. I wonder if that can really be disastrous or not (only "few nodes" affected).
On the other hand, I already violated that postulat when I introduced a tempo bonus (all things equal add bonus if your turn to play). The bonus was small, but all nodes are affected, and it's surprising that it didn't have disastrous effects. I still don't uinderstand how this works, but it does...

[Michel]

However it violates the most fundamental postulat of the negamax algorithm: score symmetry [for all position P, score(P, White to play) + score(P, Black to play) = 0].

This is not a fundamental postulate at all. The side to move is just
a property of the position (that's why the stm property gets its own zobrist hash key).

[hgm]

That is not a postulate of negamax at all. Minimax is based on having a zero-sum game, but that only means the scores for white and black should be opposite in the same game state, i.e. with the same side to move. What happens with different stm is totally irelevant. In fact almost none of the positions would get a score from search that is equal before and after null move. So why should nodes where you stand pat be different?

The only way you can hurt yourself is when you have an eval cache and forget to include stm in the hash key, when your eval is stm-dependent.

(In the last Chess War there was a funny win by micro-Max, where it attacked the opponent's Queen with a Knight. This was no problem, because the Queen could easily move away to a safe square. Then a tempo was wasted, and the opponent could move the Queen back to the square attacked by the Knight, getting back to the same position, which it had already scored as harmless. Except that now uMax had the move, so it simply took the Queen, game over... It mattered a lot in that position who had the move, scorewise! )