Evaluation Scaling

[jordanbray]

I'm testing out some endgame logic, and have been slowly implementing each endgame type. I was working on a QvR endgame section (which I'm only putting in for completeness. In reality these are decided by tactics that win the rook). However, at a very low depth search, for some reason the second set of code works better than the first.

The only positions that this has been tested with are QvR endgames. So this isn't an issue of trading into a won endgame or something like that. Q vs no pieces will always return a larger score in both cases.

Code: Select all

    int score = 1000 + 5 * (100 + magic_get_king_distance(losing_king, losing_rook) * 1 -
                       opponent_king_edge_distance(ei) * 1 -
                       opponent_king_corner_distance(ei) * 2 -
                       kings_distance(ei) * 16);

vs

Code: Select all

    int score = 1000 + 100 + magic_get_king_distance(losing_king, losing_rook) * 1 -
                       opponent_king_edge_distance(ei) * 1 -
                       opponent_king_corner_distance(ei) * 2 -
                       kings_distance(ei) * 16;

For some unknown reason, the first section of code performs significantly better than the second set of code. Again, this is on a limited depth search so the test is infinitely repeatable. I have no idea why this would occur. I hope that maybe you guys have some insight as to why the engine would prefer the larger score being returned.

Thanks,
Jordan

[elcabesa]

I suppose that 1000 is a high value, higher then the maximum material difference you can have on the board.
you also add 100 to this value but kings_distance(ei) * 16 could be higher than 100, so you could have values smaller than 1000. Are you sure that ?some result aren't smaller than normal search values?

[jordanbray]

I suppose that 1000 is a high value, higher then the maximum material difference you can have on the board.
you also add 100 to this value but kings_distance(ei) * 16 could be higher than 100, so you could have values smaller than 1000. Are you sure that ?some result aren't smaller than normal search values?

I am sure of that, because I'm *only* playing QvR games. I have created a short "opening book" where that is the only type of endgame played. Material evaluation isn't looked at when these endgame functions are called. In fact, this is the only evaluation paramater looked at.

The only time this evaluation parameter is not looked at is after the rook has been captured, and the score will go way up.

[elcabesa]

so you are playing only engames?

maybe the larger scores are filtered by aspiration windows

[Ferdy]

I'm testing out some endgame logic, and have been slowly implementing each endgame type. I was working on a QvR endgame section (which I'm only putting in for completeness. In reality these are decided by tactics that win the rook). However, at a very low depth search, for some reason the second set of code works better than the first.

The only positions that this has been tested with are QvR endgames. So this isn't an issue of trading into a won endgame or something like that. Q vs no pieces will always return a larger score in both cases.

Code: Select all

    int score = 1000 + 5 * (100 + magic_get_king_distance(losing_king, losing_rook) * 1 -
                       opponent_king_edge_distance(ei) * 1 -
                       opponent_king_corner_distance(ei) * 2 -
                       kings_distance(ei) * 16);

vs

Code: Select all

    int score = 1000 + 100 + magic_get_king_distance(losing_king, losing_rook) * 1 -
                       opponent_king_edge_distance(ei) * 1 -
                       opponent_king_corner_distance(ei) * 2 -
                       kings_distance(ei) * 16;

For some unknown reason, the first section of code performs significantly better than the second set of code. Again, this is on a limited depth search so the test is infinitely repeatable. I have no idea why this would occur. I hope that maybe you guys have some insight as to why the engine would prefer the larger score being returned.

Thanks,
Jordan

May I know what is magic_get_king_distance(losing_king, losing_rook)?

However, at a very low depth search, for some reason the second set of code works better than the first.

For some unknown reason, the first section of code performs significantly better than the second set of code. Again, this is on a limited depth search so the test is infinitely repeatable.

One way to better understand the situation is to test at multiple fixed depth. Run depth 1, 2, 3 and so on (deeper is better) Establish a base line, example.
1. Default: Without the QvR code
2. Code1:
3. Code2:

Match Default v Code1, at multiple depths
Match Default v Code2, at multiple depths

Graph the performance of Code1 and Code2, at y-axis and depth at x-axis for both codes.