An Evaluation Mystery ?

[hgm]

Fruit does it this way, and I have discussed here on several occasions how I implemented a generalized case in Fairy-Max, to create the Pair-o-Max derivative.

The drawishness correction in general is triggered by a shortage of Pawns for the leading side. (No Pawns at all, or a single one for which the opponent can afford to sacrifice his least-valuable piece.) Typical reduction factors for such cases are 1/2, 1/4, 1/8, 1/26 or even a hard 0, depending on how bad the situation is. A situation where your last Pawn has already been sacrificed away, is obviously worse than one where this still has to be done, because perhaps you can prevent the sacrifice.

A case that is not that easy to generalize is "unlike Bishops". Basically this is a penalty for color-binding of the strong side's remaining piece, but it is not clear what properties exactly the defending piece should have to be able to exploit this weakness. A Bishop is a pretty ideal defender, because it can guard the squares in front of two far-apart Pawns, while still not bound to a particular location on the board where the attacking King might be able to chase it away. So all you have to worry about is neutralizing the attacking King with your own. So it could very well be that the minimum defender needed to make a color-bound attacker drawish is indeed a Bishop. Although Chu Shogi's "Side Mover" might be able to do it too, in cases where the Pawns are an even number of files apart.

[tpetzke]

In endgames where most of the positions are DRAW the draw-recognizer is implemented indirectly.

Read it as

This position is DRAW except
1) condition A
2) condition B
etc...

Take KRKR as an easy example

DRAW unless
the attacker (side to move) can capture the undefended rook
the defender is to move but its rook is pinned
the attacker is to move and can pin the rook
the defender king is at the edge and can be checked and forced into a pin
etc ...

KRKB is similar

Thomas...

[Sven]

Take KRKR as an easy example

DRAW unless
the attacker (side to move) can capture the undefended rook
the defender is to move but its rook is pinned
the attacker is to move and can pin the rook
the defender king is at the edge and can be checked and forced into a pin
etc ...

I don't understand what you mean. KRKR and pins? Do you mean a skewer (in german "Spieß")? And who is in the role of "attacker" and "defender" in case of KRKR?

I would rather use more conservative rules like these:
KRKR can be evaluated as a draw unless
- the moving side is in check (can be excluded by search), or
- either of the two rooks is currently attacked by the king, or
- the kings are in opposition or knight distance.
I would not prune the subtree of such positions in search but rather just return a draw score in static eval.

KRKB is similar

I don't think that KRKB is similar to KRKR. The winning chances for the rook side are much more subtle, and the bishop side must be much more careful in some cases. Some positions are simple draws, and you can identify these based on simple criteria like "king in corner of color opposite to bishop, and bishop directly near king". But the general case is more complex.

For both KRKR and KRKB, as well as other cases, using bitbases or tablebases is much more accurate, of course, but that is a different approach.

Sven

[tpetzke]

Hi Sven,

In KRKR I defined the attacker as the one that has the move when I evaluate the position.

A pin in KRKR is when one side checks the king or can check the king and the king move exposes the undefendable rook

I would not prune the subtree of such positions in search but rather just return a draw score in static eval.

Yeah, but I want to prune the whole sub tree. Therefore I made the recognizer perfect meaning it will never announce a DRAW that is actually a WIN. It might however respond with UNKNOWN in case one of the exceptions triggers unnecessarily (sometime I rule out to much to keep the rules simpler).

In case of KRKR it took 10 rules to formulate all the exceptions and the module finds

Incorrect Draws : 0
Spotted Draws : 11.547.632
Missed Draws : 3.590.432
Spotted Wins/Losses : 6.423.392

KRKB is handled the same as it is a DRAW unless I spot an exception. It just has more exceptions and it therefore misses a bit more draws. But this is not a problem. Search will find out very quickly if the weaker side can force a position that is known as draw.

iCE has a lot of those modules as I don't want to use endgame table bases. I wanted to write a chess engine and not a database client. I think that iCE is probably the only engine that does it this way. It is probably not worth very much in terms of ELO but it makes iCE special.

Thomas...

[AlvaroBegue]

the defender is to move but its rook is pinned

In KRKR I defined the attacker as the one that has the move when I evaluate the position.

Now I am even more confused...

[Sven]

In KRKR I defined the attacker as the one that has the move when I evaluate the position.

I understand but you contradicted to that by writing once "the defender is to move but ...". As I now see Alvaro is confused as well ...

A pin in KRKR is when one side checks the king or can check the king and the king move exposes the undefendable rook

That is not the usual definition of "pin", at least. What you describe is known to me as a "skewer".

I would not prune the subtree of such positions in search but rather just return a draw score in static eval.

Yeah, but I want to prune the whole sub tree. Therefore I made the recognizer perfect meaning it will never announce a DRAW that is actually a WIN. It might however respond with UNKNOWN in case one of the exceptions triggers unnecessarily (sometime I rule out to much to keep the rules simpler).

In case of KRKR it took 10 rules to formulate all the exceptions and the module finds

Incorrect Draws : 0
Spotted Draws : 11.547.632
Missed Draws : 3.590.432
Spotted Wins/Losses : 6.423.392

KRKB is handled the same as it is a DRAW unless I spot an exception. It just has more exceptions and it therefore misses a bit more draws. But this is not a problem. Search will find out very quickly if the weaker side can force a position that is known as draw.

iCE has a lot of those modules as I don't want to use endgame table bases. I wanted to write a chess engine and not a database client. I think that iCE is probably the only engine that does it this way. It is probably not worth very much in terms of ELO but it makes iCE special.

I really appreciate your last point regarding iCE and making your engine "special" or even "unique" that way. I just think, as Evert already pointed out, that doing so will slow down your whole search. It is certainly correct if you implement a "perfect" draw recognizer but I'm not so sure whether it is worth the effort, compared to a bitbase. But I understand your reason why you don't want to use bitbases or tablebases in your engine.

Sven

[hgm]

Why do you think his approach would be slower? The code would not be executed except when you really hit that end game. And it is not so much code that it would not fit in the L2 cache. For bitbases that might not be the case, and the probe would require a costly memory access.

I don't know how deep on average he would have to search to reach a position where the recognizer cuts off. He seems to recognize a quite large fraction of all positions. (If I count well there would be 16M wtm and 16M btm positions with 4 pieces, and he reports 17M as recognized, which is more than 50%.)

[Sven]

Why do you think his approach would be slower? The code would not be executed except when you really hit that end game. And it is not so much code that it would not fit in the L2 cache. For bitbases that might not be the case, and the probe would require a costly memory access.

If you can implement those 10 rules for a perfect KRKR draw recognizer without such a "costly memory access" then you're indeed a magician.

Sven

[tpetzke]

I understand but you contradicted to that by writing once "the defender is to move but ...". As I now see Alvaro is confused as well ...

Yes, this is of course non-sense. Sorry.

It doesn't slow down the search because the resulting tree gets cut heavily or in most cases there is no tree below. And those recognizers are only called anyway if the piece count drops below 6.

It is not worth the effort ELO wise, I agree. And the effort is significant. KRKR was simple, but there were ones that were quiet complicated. But ELO is not everything, to create a 3000+ engine is not so difficult nowadays (although "create" might not to be the best word for that).

Thomas...

[Evert]

iCE has a lot of those modules as I don't want to use endgame table bases. I wanted to write a chess engine and not a database client. I think that iCE is probably the only engine that does it this way.

I wouldn't be so sure.

Although Jazz doesn't use the evaluators for pruning decisions (yet), it's something I do plan to look at. I've considered whether bitbases might be worth it, but it feels so clunky (and they do become huge if you want many of them).