question on draw evaluation

[liuzy]

Some draw endgames require not only the pure material is under centain conditions, but also require the position of some pieces are eligible if they are not the strong side.
To analyse the position condition in the evaluation function, or just let search to do it, which choice is better?

[Onno Garms]

The search will never detect draw by e.g. wrong bishop. If you want to detect this without tablebases, you will have to do it in eval.

[bob]

The search will never detect draw by e.g. wrong bishop. If you want to detect this without tablebases, you will have to do it in eval.

Actually it will, either by 3-fold repetition, eventually, or the 50 move rule. But that takes hopelessly long and you will already be in the position for many moves before you realize this, rather than realizing it and avoiding the position when you have the opportunity to do so.

[wgarvin]

The search will never detect draw by e.g. wrong bishop. If you want to detect this without tablebases, you will have to do it in eval.

Actually it will, either by 3-fold repetition, eventually, or the 50 move rule. But that takes hopelessly long and you will already be in the position for many moves before you realize this, rather than realizing it and avoiding the position when you have the opportunity to do so.

I think Onno's answer is correct. The question was about draws by material or piece position, such as a draw because its KNK.

But rather than eval, I think the best place to detect this would be interior node recognizers (or in the same place where you do tablebase lookups during search).

[bob]

The search will never detect draw by e.g. wrong bishop. If you want to detect this without tablebases, you will have to do it in eval.

Actually it will, either by 3-fold repetition, eventually, or the 50 move rule. But that takes hopelessly long and you will already be in the position for many moves before you realize this, rather than realizing it and avoiding the position when you have the opportunity to do so.

I think Onno's answer is correct. The question was about draws by material or piece position, such as a draw because its KNK.

But rather than eval, I think the best place to detect this would be interior node recognizers (or in the same place where you do tablebase lookups during search).

It really isn't correct. Opposite colored bishops are not automatic draws. They become draws when you can't make progress and run into the 50 move rule or the 3-fold repetition rule. Search _can_ find that, given enough time, as I mentioned. Most opposite-colored-bishop games are not drawn. There are some trivial cases, KBP vs KB with opposite-colored B's that is either won on the move, or else drawn once the bishop cuts off the path to the queening square.

Do you want to depend on search? Of course not. But it _will_ do the job given enough time.

[metax]

It really isn't correct. Opposite colored bishops are not automatic draws. They become draws when you can't make progress and run into the 50 move rule or the 3-fold repetition rule. Search _can_ find that, given enough time, as I mentioned. Most opposite-colored-bishop games are not drawn. There are some trivial cases, KBP vs KB with opposite-colored B's that is either won on the move, or else drawn once the bishop cuts off the path to the queening square.

Do you want to depend on search? Of course not. But it _will_ do the job given enough time.

I think with "wrong bishop" he meant something like this:

[D]1k6/6B1/8/8/PK6/8/8/8 w - -

and not opposite-colored bishop endgames.

[bob]

It really isn't correct. Opposite colored bishops are not automatic draws. They become draws when you can't make progress and run into the 50 move rule or the 3-fold repetition rule. Search _can_ find that, given enough time, as I mentioned. Most opposite-colored-bishop games are not drawn. There are some trivial cases, KBP vs KB with opposite-colored B's that is either won on the move, or else drawn once the bishop cuts off the path to the queening square.

Do you want to depend on search? Of course not. But it _will_ do the job given enough time.

I think with "wrong bishop" he meant something like this:

[D]1k6/6B1/8/8/PK6/8/8/8 w - -

and not opposite-colored bishop endgames.

Same thing. Search will eventually end up at a 3-fold repetition or 50-move draw. That's the point of encoding these rules. Of course this is better done in the evaluation, and for this case (bishop + wrong rook pawn) many programs do evaluate it as an outright draw via special code in the eval. Crafty has done this for years. Even versions of Cray Blitz had code to recognize this kind of drawn position (we had to avoid trading into a +4 position (ahead bishop + pawn) that was a dead draw. But for any of these cases, search will eventually recognize the draw, because that is what search does when it can reach sufficient depth.

[metax]

Same thing. Search will eventually end up at a 3-fold repetition or 50-move draw. That's the point of encoding these rules. Of course this is better done in the evaluation, and for this case (bishop + wrong rook pawn) many programs do evaluate it as an outright draw via special code in the eval. Crafty has done this for years. Even versions of Cray Blitz had code to recognize this kind of drawn position (we had to avoid trading into a +4 position (ahead bishop + pawn) that was a dead draw. But for any of these cases, search will eventually recognize the draw, because that is what search does when it can reach sufficient depth.

Well, that's obvious. Search will do everything if you give it enough time...
I was referring to your sentence "Opposite colored bishops are not automatic draws", however, because it sounded like you hadn't understood what he meant by "wrong bishop".

[Houdini]

Some draw endgames require not only the pure material is under centain conditions, but also require the position of some pieces are eligible if they are not the strong side.
To analyse the position condition in the evaluation function, or just let search to do it, which choice is better?

Engines that rely on search only will make the wrong decision when trading into certain endgames that appear to be winning, but are in fact drawn. Below some examples of basic endgames that a strong human player will recognize as draw, but most engines not:
[D]6k1/8/6PP/7K/8/2b5/8/5B2 w - - 0 1
[D]8/2K5/3P4/2k2b2/8/8/4B3/8 w - - 0 1
[D]4R3/1K6/8/2k1p3/8/8/8/8 b - - 0 1
[D]7Q/8/8/4K3/8/8/2pk4/8 w - - 0 1
Without tablebases or special evaluation code an engine will require a very deep search to establish a draw score.

[bob]

Same thing. Search will eventually end up at a 3-fold repetition or 50-move draw. That's the point of encoding these rules. Of course this is better done in the evaluation, and for this case (bishop + wrong rook pawn) many programs do evaluate it as an outright draw via special code in the eval. Crafty has done this for years. Even versions of Cray Blitz had code to recognize this kind of drawn position (we had to avoid trading into a +4 position (ahead bishop + pawn) that was a dead draw. But for any of these cases, search will eventually recognize the draw, because that is what search does when it can reach sufficient depth.

Well, that's obvious. Search will do everything if you give it enough time...
I was referring to your sentence "Opposite colored bishops are not automatic draws", however, because it sounded like you hadn't understood what he meant by "wrong bishop".

I took it in the more liberal sense. Which would include both B + wrong rook pawn or B vs opponent's opposite-colored B.