An Evaluation Mystery ?

[Chan Rasjid]

Hello,

[d]8/3rk3/8/8/4B3/2K5/8/8 w - - 0 1

[d]8/3rk3/4r3/8/2RB4/3K4/8/8 w - - 0 1

I have implemented a routine to evaluate only KBxKR, evalBR().

My program was made to play the above 2 positions. I monitor if the routine was called. The surprise is that it was never called! I expected that somehow quite moves are made in some lines and horizon would be reached with a B and a R and evalBR() would be called. It did not happen!

It was otherwise with a KPK position. My routine for evalKpk() was called.

Why?

Best Regards,
Rasjid.

[AlvaroBegue]

It sounds like a bug.

[tpetzke]

I would say that the code that forks to the correct evaluator for a material signature is buggy.

Thomas...

[Chan Rasjid]

It sounds like a bug.

Tell me I am that bad in progamming!
numpc[0][0] is all while pieces counting the king:

Code: Select all

    if (numpc[0][0] == 2 && numpc[1][0] == 2
            &&
            ((numpc[0][Bishop] == 1 && numpc[1][Rook] == 1)
            || (numpc[1][Bishop] == 1 && numpc[0][Rook] == 1))

            ) {
        /* loss if wrong bishop */
        return evalBR(side);
    }

My codes have passed many many asserts! And play very normally. If the global arrays numpc[2][8] were wrong, I expected a big issue.

Since others suspect it is a bug, it somehow must be.

Best Regards,
Rasjid.

[Evert]

What happens if you set up a position where rooks can be exchanged immediately? Surely that's a better test?

By the way, what's in a KRKB evaluation function? Shouldn't you just drag the score close to 0 (to make it clear that the position is "drawish") and leave the rest to the search?

[tpetzke]

I have a KRKB eval that checks for draws. If one is found search is terminated and only if the position is not recognized the score becomes drawish.

This helps the engine to find the winning paths in those positions that are not draws like

[D] 8/8/8/8/8/2R5/8/3K1bk1 w - - 0 1

Mate in 29

Thomas...

[AlvaroBegue]

What kinds of conditions allow you to determine the position is a draw?

[Chan Rasjid]

Hello,

What happens if you set up a position where rooks can be exchanged immediately? Surely that's a better test?

By the way, what's in a KRKB evaluation function? Shouldn't you just drag the score close to 0 (to make it clear that the position is "drawish") and leave the rest to the search?

[d]8/2rrk3/8/8/2RB4/3K4/8/8 b - - 0 1

Some programs do immediately choose to exchange a rook. Still my exit(-1) was not triggered.
I can't believe there is a bug in numpc[][].

I was looking into the evaluation of Fruit and notice it has evaluations using internal node recognizer for many typical endgame drawn positions. I had the wiki page wrong (color) bishop and implements what I found there.

I successfully implemented the KPBxK draw for the wrong rook-pawn case. With it, my program knows how to draw against komodo. There is also mentioned a draw of KBxKR and so I tried implementing it in a evalBR().

For the 1st position of KBxKR, all programs jazz, redqueen, octochess,etc playing the weaker side could draw komodo. Only my program and another weaker program, simplex, could not. But my program currently has no pruning at all - no futility, LMR or nullmove pruning. I am not sure if search matters here. If evaluation matters, I am not sure what is there to evaluate with a single bishop facing a single rook.

Could you clarify the technique "just drag the score close to 0 (to make it clear that the position is "drawish") and leave the rest to the search"

Best Regards,
Rasjid.

[Evert]

I have a KRKB eval that checks for draws. If one is found search is terminated and only if the position is not recognized the score becomes drawish.

This helps the engine to find the winning paths in those positions that are not draws like

[D] 8/8/8/8/8/2R5/8/3K1bk1 w - - 0 1

Mate in 29

Right, I forgot that I actually put this in Jazz recently. Given enough time it solves the position just fine, but it needs a long time to find some of the rook moves early on. Once the defending king is on the h file it goes quickly.

The difference is that in Jazz I recognise the "dead draw" positions in the evaluation, but not in the search so the branches are not pruned. Perhaps there is something to be gained here in cases where the evaluation returns 0 for unequal material (indicating a recognised draw position), but it may slow down the search in the more general case...

[tpetzke]

Could you clarify the technique "just drag the score close to 0 (to make it clear that the position is "drawish") and leave the rest to the search"

Usually if you encounter a KRKB position in eval assign it a score close to 0, because a draw is likely.

If you encounter such a position in search (not at a leaf node) continue searching. This avoids easy errors where the bishop moves into a pin or so.

If you want to improve that then you have to implement a recognizer that is able to classify a position as DRAW or UNKNOWN. In case of UNKNOWN you continue searching in case of DRAW you can stop and return 0.

Thomas...