Draw scores

[bob]

Let me start off by saying that I'm an idiot. That seems to be the best explanation for why I'm having trouble with this.

I've written a few very minor chess programs over the years. I don't like playing chess, only programming chess, so I never really cared how well they played. I just had fun writing them.

Now I'm trying to make my new one work properly, so I now care about the little details.... like draw scores.

Solving one issue brings up another problem. Solving that one creates ye another, etc. My simple problem has ballooned into several issues and fixing them has become a problem all to itself.

By the time I do all the solutions, it's one heck of a kludge. A wart on a wart.

Obviously I'm doing something wrong. I'm missing something obvious.

When a solution to a simple problem becomes this complicated, something is wrong.


Issue 1)
If you do a draw score of zero, then the program can not tell the difference between a draw in 3 moves from a draw in 33 moves. One draw looks as good as another to the search, so it just picks randomly among them.

Before you go on, you should read the paper Harry Nelson wrote titled "The draw heuristic in Cray Blitz". We addressed this very issue,

I don't think I happen to have that article. I only have a few from back then. And I don't see it posted on your website.

but it has its own set of issues as you mentioned. We uses real scores that had a "gap" between 0 and 100 (pawn = 1000 in Cray Blitz), and we squeezed the draw scores into that range based on the ply where they are discovered. The problem is that draw scores (except for insufficient material) are path-dependent, and hashing ignores the path. So we were seeing scores like draw in 90 plies, even though CB had a max depth of 64 plies. We just accepted that, knowing that some draws were getting pushed out to appear that they happened beyond 100 plies, making them move into the real (non-draw score) area.

Well, hashing is its own problem. That the failure of the hash and too small of a draw window and not limiting its max draw score.

That's not relevant to the basic search issues I was asking about.

Admittedly I hadn't thought about hashing issues for draw scores. But I haven't added hashing to this program yet, so it's not relevant.

In cases where there are multiple draws at the root (and even in the search), the program picks randomly among them. Leading to the possibility of the program playing back & forth between them and never actually getting around to doing the draw. This is similar to why programs give a bonus to mates that are closer to the root than others.

There are a few infamous games where a program couldn't choose between several mates and ended up loosing the game. The draw problem seems to be the same issue.

The solution, of course, is to give a bonus to draws that are closer to the root. Say, 1000-Ply. (That assumes we have a 1000 point window around zero just for draw scores. Don't have to, it just makes this discussion easier.) That leads to issue 2.


Issue 2)
If you give a draw score a non-zero value, then that means a draw can have a negative score, after its been backed up the search and negated by NegaMax.

That seems to be absurd. It shouldn't be negative. A draw is a draw, no matter who plays it. It's not bad or good. It simply 'is'.

You can ignore that, but that leads to issue 3.


Issue 3)
If you allow a draw score to be negative, then that causes problems for the search. You end up with cases where shorter or longer draws appear better because of the sign.

Assume, for example, that we search ply 1 move 1 and discover that it has a draw score of "draw in 2 moves", or 9998 in this scoring system. That score backs up to the first ply and it becomes -9998 because of the NegaMax negation.

This is really a non-issue. if you reserve scores between -1000 and +1000 for draws, it will work, in that anything in that range is a draw.

Right.

Note that more distant draws for white are favorable according to your definition, so for black less distant (more immediate) draws are more favorable, and that is what will happen. But you still have the hash issue to deal with and that is significant.

Don't worry about the score issue. That was just off my head scores while I was writing the message.

I was more concerned about trying to be clear rather than making sure I had crossed by T's and dotted my I's.

But the issue still exists whether the score is that way or the other way.

But point taken. When I do the draw scoring in my program, I'll make sure they are right.

That sets Alpha to -9998 and beta is still at +Infinity.

Ply 1 move 2. It has a=-9998 & B=+Inf. It makes the move and recurses.

Ply 2 move 1. It has a=-inf & b=+9998. It makes the move and recurses.

Ply 3... alpha=-9998 & beta=+Inf.
We discover it's a draw. we return the score 1000-Ply = 9997

Back at ply 2 move 1, we negate that return score of 9997 to -9997. That becomes the best move.

There are no more moves at ply 2, so we back up to ply 1.

Back at ply 1, that score of -9997 gets negated by NegaMax and becomes 9997.

So, now at ply 1, we have a case where a draw in two moves has a score of -9998 and a draw in 3 moves has a score of 9997.


Because the draws happened on different plies, they got negated a different number of times and the result is the signs are different.

This causes the search to pick draws at odd plies over draws at even plies. In other words, with this method, it prefers a draw at ply 33 over a draw at ply 2.


That's not right behavior. A draw is a draw. It doesn't matter who does it. (ie: what ply.)

Not within the minimax framework. If a draw in 10 is good for me, a draw in less than 10 is better for my opponent, otherwise the min-max approach won't work at all. However, I think it better to ignore the idea with one exception that we use in Crafty explained below.

Draw in 10 moves vs. draw in 20 moves or some such is one thing.

But when you start getting into negative draw scores (because of NegaMax), then something isn't right.

That's the issue... Draws *aren't* bad. They simply are. They are the same to both sides.

Rarely is that true. If I have a better position, I clearly do _not_ want to draw. So it is bad from my perspective. But if I have a better position, you, by definition, have a worse position, and you would be happy to take a draw given the opportunity.

So - draw scores are perfectly OK, they just represent cases where the _other side_ is forcing the draw, probably meaning you are unhappy about it. That is exactly how positional scores work if you think about it.

Sure, one side may want to postpone it, and pick the furthest. That's to be expected and NegaMax works fine for that.

But when it start negating it, that's when other problems start to show up.

It's not like checkmate, where it's important who gets mated. A draw simply 'is'. It happens equally to both players.

You are way over-analyzing this. Minmax simply finds the best score for me, period. If a draw is better than everything else, it will find it. If a draw is worse than everything else, it will not follow that path. And the same logic works for the opponent as well. So in reality, it is exactly like checkmate, or any other positional score. You want the largest score you can force your opponent to accept, he wants the smallest score he can force you to accept.

mate. draw. or positional. They all work exactly the same.

A draw score should never be negative.

What do you base that on? Can mate scores be negative? Why? What about positional scores? If those can be negative, what is different about a draw?

Issue 4)
Fixing #3 means not negating draw scores. Leaving draw scores always positive. Solves that. We have to keep a draw score always seperate from a heuristic score, hence the use of the 1000 point window around zero. We could use a flag passed back. That'd work just as well.

However, doing that fix also means we have to *always* be sure and not negate the draw scores. Including where we recurse and swap & negate the alpha & beta scores.




At this point I've got 3 fixes for what seemed to be a simple issue.

It's starting to get complicated and when a solution starts getting this complicated, you know something is wrong with your original thought. It's time to rethink. Or ask for help.


So, if something is wrong with my reasoning, then I must be an idiot because it looks like the reasoning is sound.

I've gone through the search process and looked at the bounds and what the scores can be (including fail-soft), and it sure looks to me like getting the right draw score is not an easy thing to do.


I know most programs don't bother with all this. (I haven't checked all of them, but a few. I don't really like browsing other programs to see how they do things, though.)

And I haven't seen any discussion about these kinds of problems. (I did browse through the CCC archives and didn't see anything there or on other web sites. I did, however, see a comment by Prof. Hyatt about draw scores getting very deep because of the hash table. But artificially limiting draw depth scores to 100 plies should solve that. You end up with issue 1 above, but for draws 100 plies away that's not really a big problem.)


So maybe the other programs just don't bother to fix the initial problem? Figuring that it's such a small problem that it's not worth the complicated fixes to make sure it always picks the best draw move?

Do they figure one draw is as good as the next, or do they not care the program will prefer draws at odd plies over even plies?


Or have I missed something obvious. (That's most likely...)


I looked for articles on dealing with exact vs. inexact scores, but all I found were a few references to some papers by Beal and to one by Slate.

This whole thing just doesn't seem to be discussed much.

The only exception I have to drawscore = 0 happens for two conditions:

(1) my draw score is dynamic (and the user can adjust it also as in "contempt setting".) But, in general, a draw score should reflect the preferred outcome based on your and your opponent's ratings. For crafty, against a weaker opponent, I have more "contempt" and will work harder to avoid draws because the drawscore goes more negative as crafty's rating goes above the opponent's rating. Ditto for the inverse case where I would prefer to draw a much higher rated opponent.

2. For endgame table draws, I would prefer a drawn KRP vs KR over a drawn KR vs KR ending. And often crafty gets to make that decision. In crafty a drawscore of 0 means drawn, material is even. A drawscore of +1 means draw, program is ahead in material. A score of -1 (-.01 of course) says the program is behind in material. The idea is that given the choice of two draws, I'd like to either take the one where my opponent has the chance to make mistakes and actually lose, or where he has to at least think and perhaps get into a bit of time trouble and then make a more serious mistake.

Alright. So if I understand you, because all draws are 0 (with the above exceptions), you are willing to allow a draw in 3 moves to have the same backed up score as a draw in 33 moves?

correct.

You don't care whether you find the shortest draw or not?

With hashing, I can't find the shortest draw, because we don't hash path information into the signature. So it isn't a matter of "don't care" but a matter of "simply no can do..."

You accept that in a game that if you play a move with a draw score, that for your next move you may not be able to find the same drawing line? That you might pick a longer drawing line?

Unless you have a bug, a draw is a draw is a draw. Doesn't matter whether it is a repetition, a 50-move rule draw, or an insufficient material draw...

To me, that seems almost as dangerous as the mate problem that made CoKo III loose because it had so many choices. It passed up a mate in 1 to try for other mates. And kept going back & forth.

By not going toward the shortest mate, they made a mistake. But what could go wrong with not going toward _any_ draw? You might draw the game another way??? Again, a draw is a draw is a draw. Against humans we were trying to capitalize on "meat makes mistakes" and go for the longest draw to give our opponent the most chances to make a mistake. But even that didn't work reliably as I have mentioned.

I don't dispute your program's ability. If I'm lucky, my program might play half as well as yours by the time I'm done.

You are the better programmer. You are the better chess player. You have far more chess programming experience than I do.

But it still seems like it's wrong.

Trust me, it is OK. negamax is a mind-bending algorithm until you get comfortable with it. Then it is like breathing or eating, it seems natural.

[Carey]

I know you like to keep quotes, but this is getting too long for me... It makes it too hard to edit and keep all the sub-quotes straight.

Draw in 10 moves vs. draw in 20 moves or some such is one thing.

But when you start getting into negative draw scores (because of NegaMax), then something isn't right.

That's the issue... Draws *aren't* bad. They simply are. They are the same to both sides.

Rarely is that true. If I have a better position, I clearly do _not_ want to draw. So it is bad from my perspective. But if I have a better position, you, by definition, have a worse position, and you would be happy to take a draw given the opportunity.

That will be taken care of by the normal comparison of draw vs. non-draw scores. Probably with a bias / contempt factor to adjust things so that you wont want to draw unless you are a couple pieces down or something.

The issue here is choosing among several draws. The shorter draw has a higher (positive) score. Again, your normal score offset / bias will take care of putting the draw score into the range of where you decide to aim for a draw versus playing for a whin.

So - draw scores are perfectly OK, they just represent cases where the _other side_ is forcing the draw, probably meaning you are unhappy about it. That is exactly how positional scores work if you think about it.

I have thought about it... That's the problem.

My line of reasoning doesn't match up with what everybody else is doing.

I can see what they are doing. But I can also envision cases where it fails.

To me, it doesn't seem to matter *who* is causing the draw. A draw is a draw. Whether it's considered good or bad depends on where you place that draw score in relation to your heuristic evaluator score (by using the offset / bias / contempt factor) And the draw depth is how you tell your program to aim towards the nearer ones.

You don't care whether you find the shortest draw or not?

With hashing, I can't find the shortest draw, because we don't hash path information into the signature. So it isn't a matter of "don't care" but a matter of "simply no can do..."

I'll certainly grant you that hashing can screw up a lot of things, including proper draw scores.

It's entirely possible that draw scores shouldn't even be hashed.

However, that's another subject, and one I'm certainly not qualified to be a part of.


But just because hashing screws up a lot of stuff doesn't mean the basic search itself should be wrong. After all, not all draws will be coming from the hash table. There's a good chance they will be in the search itself and you'll know for sure how deep they are.

You accept that in a game that if you play a move with a draw score, that for your next move you may not be able to find the same drawing line? That you might pick a longer drawing line?

Unless you have a bug, a draw is a draw is a draw. Doesn't matter whether it is a repetition, a 50-move rule draw, or an insufficient material draw...

I don't keep track of what kind of draw it is.

I used to in my old programs. That and more stuff. But I never used it, so this time I got rid of the info.

To me, that seems almost as dangerous as the mate problem that made CoKo III loose because it had so many choices. It passed up a mate in 1 to try for other mates. And kept going back & forth.

By not going toward the shortest mate, they made a mistake. But what could go wrong with not going toward _any_ draw? You might draw the game another way??? Again, a draw is a draw is a draw. Against humans we were trying to capitalize on "meat makes mistakes" and go for the longest draw to give our opponent the most chances to make a mistake. But even that didn't work reliably as I have mentioned.

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

You pick some other drawing move. It may be a much longer draw. You might even go back to the square you just moved from.

If your program can't tell the difference (in the search itself) between a draw in 20 and a draw in 2, then why would you expect it to always pick the draw in 2?

(Alright, that's extreme. With iterative search you will probably find the shorter draw. But with search extensions, you might not. But draws in 10 & 12 are close enough you could easily find them at the iter level.)

Meanwhile the opponent is making progress, doing real work. The draws you keep finding keep getting deeper and deeper. Instead of 2 ply, it became 4 ply, then 6 ply, then 12 ply.

Your program is still finding a draw. Any draw. So it's happy. It doesn't know that the draw is getting further & further away.

A draw depends on you doing everything you can to draw while your opponent does everything he can to avoid it. (ie: minimax, negamax.)

When you don't keep your part of the bargin (ie: you aren't maximizing), it breaks down. You are no longer picking the best move, but simply 'a' move. (It'd be sort of like randomly picking among the top several moves.)

And you are burning clock time in the process. Who knows, after a few wasted aimless draw moves, you might have lost enough time that your search doesn't even see the draw anymore.

Will it actually happen? I don't know. I'd say that the stronger your program is, the less chance of that happening. The more likely it is to either win or loose, instead of draw.

For a weaker program, like mine will be, drawing could be a darn good thing to aim for. And if it doesn't know which draw to take, it could waste several moves aimlessly going from one drawing move to another, until it runs out of time or finds the draw-in-1 by luck.

I don't dispute your program's ability. If I'm lucky, my program might play half as well as yours by the time I'm done.

You are the better programmer. You are the better chess player. You have far more chess programming experience than I do.

But it still seems like it's wrong.

Trust me, it is OK. negamax is a mind-bending algorithm until you get comfortable with it. Then it is like breathing or eating, it seems natural.

I've been doing NegaMax (mostly) off & on for 15 years. I'm tolerably comfortable with it. (Not as good as you are, but I manage. There are *lots* of better chess programmers than I am. No question about that. But I am reasonable comfortable with recursion & NegaMax.)

That's why I think this draw problem really is a problem. (Well, as big as any draw can cause a problem. If you always win or loose but never draw, then this whole thing is totally irrelevant.)

If a program has only one draw, then it'll do fine. But if it starts having several, then there is nothing to stop it from picking among them at random. (Well, as random as your move ordering is and your time control & hashing will allow.)

Then it's just a matter of hoping the program will pick a move where it can keep seeing the draw later. As long as it can see the draw, it will probably eventually find it. (Aimlessly, which is kind of pathetic, but as long as it can see the draw, it will probably find it.)

If it can't search as deep due to time control or the move ordering methods (hash, etc.) change things enough that it can no longer find the draw in the time alloted, then it has a real problem.

[bob]

I know you like to keep quotes, but this is getting too long for me... It makes it too hard to edit and keep all the sub-quotes straight.

Draw in 10 moves vs. draw in 20 moves or some such is one thing.

But when you start getting into negative draw scores (because of NegaMax), then something isn't right.

That's the issue... Draws *aren't* bad. They simply are. They are the same to both sides.

Rarely is that true. If I have a better position, I clearly do _not_ want to draw. So it is bad from my perspective. But if I have a better position, you, by definition, have a worse position, and you would be happy to take a draw given the opportunity.

That will be taken care of by the normal comparison of draw vs. non-draw scores. Probably with a bias / contempt factor to adjust things so that you wont want to draw unless you are a couple pieces down or something.

Actually in CB we did the _opposite_. We always thought "we have a draw in hand, so we are going to take the longest possible path to get to it, to give our opponent (human) a chance to make a mistake."

The issue here is choosing among several draws. The shorter draw has a higher (positive) score. Again, your normal score offset / bias will take care of putting the draw score into the range of where you decide to aim for a draw versus playing for a whin.

So - draw scores are perfectly OK, they just represent cases where the _other side_ is forcing the draw, probably meaning you are unhappy about it. That is exactly how positional scores work if you think about it.

I have thought about it... That's the problem.

My line of reasoning doesn't match up with what everybody else is doing.

I can see what they are doing. But I can also envision cases where it fails.

To me, it doesn't seem to matter *who* is causing the draw. A draw is a draw. Whether it's considered good or bad depends on where you place that draw score in relation to your heuristic evaluator score (by using the offset / bias / contempt factor) And the draw depth is how you tell your program to aim towards the nearer ones.

If you don't care who forces the draw, you miss an opportunity to do something right. In any draw, one side wants it, and one side doesn't. Otherwise this isn't a zero-sum game.

You don't care whether you find the shortest draw or not?

With hashing, I can't find the shortest draw, because we don't hash path information into the signature. So it isn't a matter of "don't care" but a matter of "simply no can do..."

I'll certainly grant you that hashing can screw up a lot of things, including proper draw scores.

It's entirely possible that draw scores shouldn't even be hashed.

However, that's another subject, and one I'm certainly not qualified to be a part of.


But just because hashing screws up a lot of stuff doesn't mean the basic search itself should be wrong. After all, not all draws will be coming from the hash table. There's a good chance they will be in the search itself and you'll know for sure how deep they are.

Unfortunately if you hash anything, you are never going to get proper draw scores. The closer you get to a draw, the more likely you are to pull scores from the hash table, and every one of them will be wrong.

You accept that in a game that if you play a move with a draw score, that for your next move you may not be able to find the same drawing line? That you might pick a longer drawing line?

Unless you have a bug, a draw is a draw is a draw. Doesn't matter whether it is a repetition, a 50-move rule draw, or an insufficient material draw...

I don't keep track of what kind of draw it is.

I used to in my old programs. That and more stuff. But I never used it, so this time I got rid of the info.

To me, that seems almost as dangerous as the mate problem that made CoKo III loose because it had so many choices. It passed up a mate in 1 to try for other mates. And kept going back & forth.

By not going toward the shortest mate, they made a mistake. But what could go wrong with not going toward _any_ draw? You might draw the game another way??? Again, a draw is a draw is a draw. Against humans we were trying to capitalize on "meat makes mistakes" and go for the longest draw to give our opponent the most chances to make a mistake. But even that didn't work reliably as I have mentioned.

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

You pick some other drawing move. It may be a much longer draw. You might even go back to the square you just moved from.

If your program can't tell the difference (in the search itself) between a draw in 20 and a draw in 2, then why would you expect it to always pick the draw in 2?

(Alright, that's extreme. With iterative search you will probably find the shorter draw. But with search extensions, you might not. But draws in 10 & 12 are close enough you could easily find them at the iter level.)

But my original question still stands, "why is that bad?" Going from a win to a loss is bad, or from a win to a draw or a draw to a loss. But now we have a guaranteed draw. So what can break if we take a longer one vs a shorter one, or vice-versa? we still end up in a draw.

Meanwhile the opponent is making progress, doing real work. The draws you keep finding keep getting deeper and deeper. Instead of 2 ply, it became 4 ply, then 6 ply, then 12 ply.

Again, a draw is a draw. Unless you have bugs that would cause you to not be able to find one after you have already done so on a previous move.

Your program is still finding a draw. Any draw. So it's happy. It doesn't know that the draw is getting further & further away.

Again, if it is a _real_ draw, it doesn't matter. The only reason a mate in N is important is that if you don't play to the shortest mate, you can end up in a repetition and draw. But we are already drawing, so...

A draw depends on you doing everything you can to draw while your opponent does everything he can to avoid it. (ie: minimax, negamax.)

When you don't keep your part of the bargin (ie: you aren't maximizing), it breaks down. You are no longer picking the best move, but simply 'a' move. (It'd be sort of like randomly picking among the top several moves.)

And you are burning clock time in the process. Who knows, after a few wasted aimless draw moves, you might have lost enough time that your search doesn't even see the draw anymore.

Will it actually happen? I don't know. I'd say that the stronger your program is, the less chance of that happening. The more likely it is to either win or loose, instead of draw.

For a weaker program, like mine will be, drawing could be a darn good thing to aim for. And if it doesn't know which draw to take, it could waste several moves aimlessly going from one drawing move to another, until it runs out of time or finds the draw-in-1 by luck.

I don't dispute your program's ability. If I'm lucky, my program might play half as well as yours by the time I'm done.

You are the better programmer. You are the better chess player. You have far more chess programming experience than I do.

But it still seems like it's wrong.

Trust me, it is OK. negamax is a mind-bending algorithm until you get comfortable with it. Then it is like breathing or eating, it seems natural.

I've been doing NegaMax (mostly) off & on for 15 years. I'm tolerably comfortable with it. (Not as good as you are, but I manage. There are *lots* of better chess programmers than I am. No question about that. But I am reasonable comfortable with recursion & NegaMax.)

That's why I think this draw problem really is a problem. (Well, as big as any draw can cause a problem. If you always win or loose but never draw, then this whole thing is totally irrelevant.)

If a program has only one draw, then it'll do fine. But if it starts having several, then there is nothing to stop it from picking among them at random. (Well, as random as your move ordering is and your time control & hashing will allow.)

Then it's just a matter of hoping the program will pick a move where it can keep seeing the draw later. As long as it can see the draw, it will probably eventually find it. (Aimlessly, which is kind of pathetic, but as long as it can see the draw, it will probably find it.)

If it can't search as deep due to time control or the move ordering methods (hash, etc.) change things enough that it can no longer find the draw in the time alloted, then it has a real problem.

You are still going under the assumption that your program _should_ take the shortest draw. I disagree. In a game vs a human GM, you can find KRPP vs KR positions that are EGTB draws. And the quickest way to draw is to give up both pawns and trade rooks. Do you really want to do that and avoid making the human show you he can draw against your two extra pawns, which is not easy???

[Chan Rasjid]

Carey wrote:-

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

If my program at root found and plays bestscore = 0(draw), it seems my opponent will not be able to avoid giving me one. If it converts to a win / loss then one side should have a bug somewhere (???)
Thats why draw_in_33 or draw-in-3 should not matter normally.

Rasjid

[hgm]

If you do a draw score of zero, then the program can not tell the difference between a draw in 3 moves from a draw in 33 moves.

I don't understand your problem. What do you mean by 'draw in N moves'? That you can convert to KK on the Nth move? Why would you care if you do that quickly or slowly, say, from KRKR? Or do you also consider KRKR a draw?

Not all draws are equal. KBPPKB can be a draw with unlike Bishops. So is KKB. But if you have the choice between converting to KBPPKB or KKB, the former is infinitely preferable. Even if you know it is a draw, your opponent might not know, and bungle it. In the second case there is no chance on that.

So it is a bad idea to score draws as zero. Of course you want to prevent KNK from scoring +3, so that the engine will prefer it to KPPK. But it is better to simply divide the score of such recognized draws by 5 or so, so that the natural ranking of "draws I am lucky to have" vs "draws that upset me" is preserved.

The problem of how much in a hurry you are to reach a position, is a general one, that is not any different for draws than in any other case. It depends on how much better or worse that position is than your current position. If it is better, you don't want to delay going there unnecessarily. If it is worse, you try to delay going there as much as possible, in the hope the opponent will bungle it, or some miracle cure reveals itself just over the horizon, by the time you get close to what now seems inescapable, and can look further ahead.

Even if you would argue that theoretical draws like KK or KBK have exact scores, this is of no importance, as usually the score of the alternatives (including current position) will not be exact. So it remains chosing a move in the face of uncertain evaluation of end leaves.

The thread on delayed-loss bonus addresses that problem. Not everyone is convinced, though, that it is worth anything to hurry up improving your position. I would say it is, but I have not done quantitative measurements on this. (My computer is currently busy finding more precise piece values for normal and fairy pieces...)

[Carey]

I know you like to keep quotes, but this is getting too long for me... It makes it too hard to edit and keep all the sub-quotes straight.

Draw in 10 moves vs. draw in 20 moves or some such is one thing.

But when you start getting into negative draw scores (because of NegaMax), then something isn't right.

That's the issue... Draws *aren't* bad. They simply are. They are the same to both sides.

Rarely is that true. If I have a better position, I clearly do _not_ want to draw. So it is bad from my perspective. But if I have a better position, you, by definition, have a worse position, and you would be happy to take a draw given the opportunity.

That will be taken care of by the normal comparison of draw vs. non-draw scores. Probably with a bias / contempt factor to adjust things so that you wont want to draw unless you are a couple pieces down or something.

Actually in CB we did the _opposite_. We always thought "we have a draw in hand, so we are going to take the longest possible path to get to it, to give our opponent (human) a chance to make a mistake."

Well, I haven't written the code yet, but in my program it'll probably be something like: "If I'm down a rook for a couple moves (meaning the loss seems to be permanent), go for the draw or you'll loose, stupid!" The exact point will be an adjustable bias offset.

My program isn't going to be too smart, not even close to what CB was, so if it ends up loosing quite a bit of material, the odds are going to be rather good it's going loose the whole game. It should take the closest draw it can find to avoid loosing.

The issue here is choosing among several draws. The shorter draw has a higher (positive) score. Again, your normal score offset / bias will take care of putting the draw score into the range of where you decide to aim for a draw versus playing for a whin.

So - draw scores are perfectly OK, they just represent cases where the _other side_ is forcing the draw, probably meaning you are unhappy about it. That is exactly how positional scores work if you think about it.

I have thought about it... That's the problem.

My line of reasoning doesn't match up with what everybody else is doing.

I can see what they are doing. But I can also envision cases where it fails.

To me, it doesn't seem to matter *who* is causing the draw. A draw is a draw. Whether it's considered good or bad depends on where you place that draw score in relation to your heuristic evaluator score (by using the offset / bias / contempt factor) And the draw depth is how you tell your program to aim towards the nearer ones.

If you don't care who forces the draw, you miss an opportunity to do something right. In any draw, one side wants it, and one side doesn't. Otherwise this isn't a zero-sum game.

That's taken care of by the bias. Whether it puts the draw into the negative or positive range. That will tell each side of the search to to go for it or avoid it.

The draw score of (Ply) simply tells the program which one is closer.

You don't care whether you find the shortest draw or not?

With hashing, I can't find the shortest draw, because we don't hash path information into the signature. So it isn't a matter of "don't care" but a matter of "simply no can do..."

I'll certainly grant you that hashing can screw up a lot of things, including proper draw scores.

It's entirely possible that draw scores shouldn't even be hashed.

However, that's another subject, and one I'm certainly not qualified to be a part of.


But just because hashing screws up a lot of stuff doesn't mean the basic search itself should be wrong. After all, not all draws will be coming from the hash table. There's a good chance they will be in the search itself and you'll know for sure how deep they are.

Unfortunately if you hash anything, you are never going to get proper draw scores. The closer you get to a draw, the more likely you are to pull scores from the hash table, and every one of them will be wrong.

Well... Not being an expert on search, I can't say much about that.

But it should still be able to find draws ine search itself.

You accept that in a game that if you play a move with a draw score, that for your next move you may not be able to find the same drawing line? That you might pick a longer drawing line?

Unless you have a bug, a draw is a draw is a draw. Doesn't matter whether it is a repetition, a 50-move rule draw, or an insufficient material draw...

I don't keep track of what kind of draw it is.

I used to in my old programs. That and more stuff. But I never used it, so this time I got rid of the info.

To me, that seems almost as dangerous as the mate problem that made CoKo III loose because it had so many choices. It passed up a mate in 1 to try for other mates. And kept going back & forth.

By not going toward the shortest mate, they made a mistake. But what could go wrong with not going toward _any_ draw? You might draw the game another way??? Again, a draw is a draw is a draw. Against humans we were trying to capitalize on "meat makes mistakes" and go for the longest draw to give our opponent the most chances to make a mistake. But even that didn't work reliably as I have mentioned.

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

You pick some other drawing move. It may be a much longer draw. You might even go back to the square you just moved from.

If your program can't tell the difference (in the search itself) between a draw in 20 and a draw in 2, then why would you expect it to always pick the draw in 2?

(Alright, that's extreme. With iterative search you will probably find the shorter draw. But with search extensions, you might not. But draws in 10 & 12 are close enough you could easily find them at the iter level.)

But my original question still stands, "why is that bad?" Going from a win to a loss is bad, or from a win to a draw or a draw to a loss. But now we have a guaranteed draw. So what can break if we take a longer one vs a shorter one, or vice-versa? we still end up in a draw.

It is *only* guaranteed if you can find the draw on the next move. And assuming you pick the same draw.

You may pick a move that chooses some other longer draw. If you do that a few times in a row, you may reach a point where the program doesn't see the draw anymore.


Remember, that's the same *exact* problem CoKo had when it played against GENIE way back in 1971.

It too thought "One is as good as any other". It had two mate-in-1, a couple mate-in-2 and several deeper ones.

It randomly picked among mates a few times and then even though the position was still technically a mate, it couldn't find it in its search. The delaying moves it had made had pushed the mate so far back that the search couldn't see it within its time limit.

When that happened, it made a move that didn't mate.

And that turned the mate into an eventual loss for it.


The issue is *NOT* whether you pick a guranteeed draw in 2 over a guaranteed draw in 20. A *guaranteed* draw is a *guaranteed* draw no matter how deep it is.

The issue is whether you push the draw so far back that your search may not be able to find it next time.

By delaying the draw for so long, you run the risk of the search not being able to find it again later. Espeically if you start running into time control issues due to wasting so much time rediscovering draws.

The only way to not delay it is to know which ones are closest. (Or which ones are the most easily found again in the next search. Usually the closest, but if the draw line is in the tablebase, then that would work just as well.)

Meanwhile the opponent is making progress, doing real work. The draws you keep finding keep getting deeper and deeper. Instead of 2 ply, it became 4 ply, then 6 ply, then 12 ply.

Again, a draw is a draw. Unless you have bugs that would cause you to not be able to find one after you have already done so on a previous move.

Your program is still finding a draw. Any draw. So it's happy. It doesn't know that the draw is getting further & further away.

Again, if it is a _real_ draw, it doesn't matter. The only reason a mate in N is important is that if you don't play to the shortest mate, you can end up in a repetition and draw. But we are already drawing, so...

"_real_" draw? I didn't realize there were imaginary draws....

Prof. Kozdrowicki would certainly disagree with you there. And he has the game score & game loss to prove it.

His program delayed the mate for so long that it no longer showed up in the search. And the program lost the game.

It didn't turn into a draw by rep.

It turned into a loss because his program couldn't make up its mind which which mating move to play and pushed it so far back that the search could no longer see it. Then it blundered and made a non-mating move.


He had a **REAL** mate. And delayed it for so long and pushed it back so deep in the search that eventually he couldn't find it.

Randomly choosing among draws is no different.

A _real_ draw is no different from a _real_ mate. It's a fixed point. It's a known, provable ending to the game. (Whether you want to go to the draw isn't the issue.)

But if you push it back too far by randomly choosing among them, then there is no reason to be sure you'll program will be able to always find it.

Your program has to eventually aim for goal. Otherwise it can be random chance as to when it eventually gets there.

A draw depends on you doing everything you can to draw while your opponent does everything he can to avoid it. (ie: minimax, negamax.)

When you don't keep your part of the bargin (ie: you aren't maximizing), it breaks down. You are no longer picking the best move, but simply 'a' move. (It'd be sort of like randomly picking among the top several moves.)

And you are burning clock time in the process. Who knows, after a few wasted aimless draw moves, you might have lost enough time that your search doesn't even see the draw anymore.

Will it actually happen? I don't know. I'd say that the stronger your program is, the less chance of that happening. The more likely it is to either win or loose, instead of draw.

For a weaker program, like mine will be, drawing could be a darn good thing to aim for. And if it doesn't know which draw to take, it could waste several moves aimlessly going from one drawing move to another, until it runs out of time or finds the draw-in-1 by luck.

I don't dispute your program's ability. If I'm lucky, my program might play half as well as yours by the time I'm done.

You are the better programmer. You are the better chess player. You have far more chess programming experience than I do.

But it still seems like it's wrong.

Trust me, it is OK. negamax is a mind-bending algorithm until you get comfortable with it. Then it is like breathing or eating, it seems natural.

I've been doing NegaMax (mostly) off & on for 15 years. I'm tolerably comfortable with it. (Not as good as you are, but I manage. There are *lots* of better chess programmers than I am. No question about that. But I am reasonable comfortable with recursion & NegaMax.)

That's why I think this draw problem really is a problem. (Well, as big as any draw can cause a problem. If you always win or loose but never draw, then this whole thing is totally irrelevant.)

If a program has only one draw, then it'll do fine. But if it starts having several, then there is nothing to stop it from picking among them at random. (Well, as random as your move ordering is and your time control & hashing will allow.)

Then it's just a matter of hoping the program will pick a move where it can keep seeing the draw later. As long as it can see the draw, it will probably eventually find it. (Aimlessly, which is kind of pathetic, but as long as it can see the draw, it will probably find it.)

If it can't search as deep due to time control or the move ordering methods (hash, etc.) change things enough that it can no longer find the draw in the time alloted, then it has a real problem.

You are still going under the assumption that your program _should_ take the shortest draw. I disagree. In a game vs a human GM, you can find KRPP vs KR positions that are EGTB draws. And the quickest way to draw is to give up both pawns and trade rooks. Do you really want to do that and avoid making the human show you he can draw against your two extra pawns, which is not easy???

This discussion is *NOT* about chosing when to take the draw. That's controled by the offset bias you use. That is an entirely seperate subject.

The point here is that if you do decide to draw, can you find the shortest one that's guaranteed to do it, or will you randomly pick among them and hope your search can still find it until you eventually do draw?

If the program doesn't know that a draw in 1 is better than a draw in 10 or draw in 100 or draw in 200, then why would you expect it to pick the closest (or the one it can be sure of finding next time.)

If for any reason, the search can't find the draw again, then you've lost the draw.

Delaying the draw gives your program more chances to not find it during the next search.

I think you phrased it "Meat makes mistakes". If because you kept delaying the draw, your search can't find it again (time control, move ordering,whatever), you just made that 'meat mistake'.

Just because you found a couple draws on move 38 in 3 minutes doesn't mean you'll be able to find it again on move 39 or 40 in 3 minutes.

After a few delaying moves, you may not even have 3 minutes to spend on finding the draw again. And instead of a draw in 20, because of the delaying moves, it could now be a draw in 22, which could take even more time to find. Time you may not have available to spend.

[Uri Blass]

I know you like to keep quotes, but this is getting too long for me... It makes it too hard to edit and keep all the sub-quotes straight.

Draw in 10 moves vs. draw in 20 moves or some such is one thing.

But when you start getting into negative draw scores (because of NegaMax), then something isn't right.

That's the issue... Draws *aren't* bad. They simply are. They are the same to both sides.

Rarely is that true. If I have a better position, I clearly do _not_ want to draw. So it is bad from my perspective. But if I have a better position, you, by definition, have a worse position, and you would be happy to take a draw given the opportunity.

That will be taken care of by the normal comparison of draw vs. non-draw scores. Probably with a bias / contempt factor to adjust things so that you wont want to draw unless you are a couple pieces down or something.

Actually in CB we did the _opposite_. We always thought "we have a draw in hand, so we are going to take the longest possible path to get to it, to give our opponent (human) a chance to make a mistake."

Well, I haven't written the code yet, but in my program it'll probably be something like: "If I'm down a rook for a couple moves (meaning the loss seems to be permanent), go for the draw or you'll loose, stupid!" The exact point will be an adjustable bias offset.

My program isn't going to be too smart, not even close to what CB was, so if it ends up loosing quite a bit of material, the odds are going to be rather good it's going loose the whole game. It should take the closest draw it can find to avoid loosing.

The issue here is choosing among several draws. The shorter draw has a higher (positive) score. Again, your normal score offset / bias will take care of putting the draw score into the range of where you decide to aim for a draw versus playing for a whin.

So - draw scores are perfectly OK, they just represent cases where the _other side_ is forcing the draw, probably meaning you are unhappy about it. That is exactly how positional scores work if you think about it.

I have thought about it... That's the problem.

My line of reasoning doesn't match up with what everybody else is doing.

I can see what they are doing. But I can also envision cases where it fails.

To me, it doesn't seem to matter *who* is causing the draw. A draw is a draw. Whether it's considered good or bad depends on where you place that draw score in relation to your heuristic evaluator score (by using the offset / bias / contempt factor) And the draw depth is how you tell your program to aim towards the nearer ones.

If you don't care who forces the draw, you miss an opportunity to do something right. In any draw, one side wants it, and one side doesn't. Otherwise this isn't a zero-sum game.

That's taken care of by the bias. Whether it puts the draw into the negative or positive range. That will tell each side of the search to to go for it or avoid it.

The draw score of (Ply) simply tells the program which one is closer.

You don't care whether you find the shortest draw or not?

With hashing, I can't find the shortest draw, because we don't hash path information into the signature. So it isn't a matter of "don't care" but a matter of "simply no can do..."

I'll certainly grant you that hashing can screw up a lot of things, including proper draw scores.

It's entirely possible that draw scores shouldn't even be hashed.

However, that's another subject, and one I'm certainly not qualified to be a part of.


But just because hashing screws up a lot of stuff doesn't mean the basic search itself should be wrong. After all, not all draws will be coming from the hash table. There's a good chance they will be in the search itself and you'll know for sure how deep they are.

Unfortunately if you hash anything, you are never going to get proper draw scores. The closer you get to a draw, the more likely you are to pull scores from the hash table, and every one of them will be wrong.

Well... Not being an expert on search, I can't say much about that.

But it should still be able to find draws ine search itself.

You accept that in a game that if you play a move with a draw score, that for your next move you may not be able to find the same drawing line? That you might pick a longer drawing line?

Unless you have a bug, a draw is a draw is a draw. Doesn't matter whether it is a repetition, a 50-move rule draw, or an insufficient material draw...

I don't keep track of what kind of draw it is.

I used to in my old programs. That and more stuff. But I never used it, so this time I got rid of the info.

To me, that seems almost as dangerous as the mate problem that made CoKo III loose because it had so many choices. It passed up a mate in 1 to try for other mates. And kept going back & forth.

By not going toward the shortest mate, they made a mistake. But what could go wrong with not going toward _any_ draw? You might draw the game another way??? Again, a draw is a draw is a draw. Against humans we were trying to capitalize on "meat makes mistakes" and go for the longest draw to give our opponent the most chances to make a mistake. But even that didn't work reliably as I have mentioned.

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

You pick some other drawing move. It may be a much longer draw. You might even go back to the square you just moved from.

If your program can't tell the difference (in the search itself) between a draw in 20 and a draw in 2, then why would you expect it to always pick the draw in 2?

(Alright, that's extreme. With iterative search you will probably find the shorter draw. But with search extensions, you might not. But draws in 10 & 12 are close enough you could easily find them at the iter level.)

But my original question still stands, "why is that bad?" Going from a win to a loss is bad, or from a win to a draw or a draw to a loss. But now we have a guaranteed draw. So what can break if we take a longer one vs a shorter one, or vice-versa? we still end up in a draw.

It is *only* guaranteed if you can find the draw on the next move. And assuming you pick the same draw.

You may pick a move that chooses some other longer draw. If you do that a few times in a row, you may reach a point where the program doesn't see the draw anymore.


Remember, that's the same *exact* problem CoKo had when it played against GENIE way back in 1971.

It too thought "One is as good as any other". It had two mate-in-1, a couple mate-in-2 and several deeper ones.

It randomly picked among mates a few times and then even though the position was still technically a mate, it couldn't find it in its search. The delaying moves it had made had pushed the mate so far back that the search couldn't see it within its time limit.

When that happened, it made a move that didn't mate.

And that turned the mate into an eventual loss for it.


The issue is *NOT* whether you pick a guranteeed draw in 2 over a guaranteed draw in 20. A *guaranteed* draw is a *guaranteed* draw no matter how deep it is.

The issue is whether you push the draw so far back that your search may not be able to find it next time.

By delaying the draw for so long, you run the risk of the search not being able to find it again later. Espeically if you start running into time control issues due to wasting so much time rediscovering draws.

The only way to not delay it is to know which ones are closest. (Or which ones are the most easily found again in the next search. Usually the closest, but if the draw line is in the tablebase, then that would work just as well.)

Meanwhile the opponent is making progress, doing real work. The draws you keep finding keep getting deeper and deeper. Instead of 2 ply, it became 4 ply, then 6 ply, then 12 ply.

Again, a draw is a draw. Unless you have bugs that would cause you to not be able to find one after you have already done so on a previous move.

Your program is still finding a draw. Any draw. So it's happy. It doesn't know that the draw is getting further & further away.

Again, if it is a _real_ draw, it doesn't matter. The only reason a mate in N is important is that if you don't play to the shortest mate, you can end up in a repetition and draw. But we are already drawing, so...

"_real_" draw? I didn't realize there were imaginary draws....

Prof. Kozdrowicki would certainly disagree with you there. And he has the game score & game loss to prove it.

His program delayed the mate for so long that it no longer showed up in the search. And the program lost the game.

It didn't turn into a draw by rep.

It turned into a loss because his program couldn't make up its mind which which mating move to play and pushed it so far back that the search could no longer see it. Then it blundered and made a non-mating move.


He had a **REAL** mate. And delayed it for so long and pushed it back so deep in the search that eventually he couldn't find it.

Randomly choosing among draws is no different.

A _real_ draw is no different from a _real_ mate. It's a fixed point. It's a known, provable ending to the game. (Whether you want to go to the draw isn't the issue.)

But if you push it back too far by randomly choosing among them, then there is no reason to be sure you'll program will be able to always find it.

Your program has to eventually aim for goal. Otherwise it can be random chance as to when it eventually gets there.

A draw depends on you doing everything you can to draw while your opponent does everything he can to avoid it. (ie: minimax, negamax.)

When you don't keep your part of the bargin (ie: you aren't maximizing), it breaks down. You are no longer picking the best move, but simply 'a' move. (It'd be sort of like randomly picking among the top several moves.)

And you are burning clock time in the process. Who knows, after a few wasted aimless draw moves, you might have lost enough time that your search doesn't even see the draw anymore.

Will it actually happen? I don't know. I'd say that the stronger your program is, the less chance of that happening. The more likely it is to either win or loose, instead of draw.

For a weaker program, like mine will be, drawing could be a darn good thing to aim for. And if it doesn't know which draw to take, it could waste several moves aimlessly going from one drawing move to another, until it runs out of time or finds the draw-in-1 by luck.

I don't dispute your program's ability. If I'm lucky, my program might play half as well as yours by the time I'm done.

You are the better programmer. You are the better chess player. You have far more chess programming experience than I do.

But it still seems like it's wrong.

Trust me, it is OK. negamax is a mind-bending algorithm until you get comfortable with it. Then it is like breathing or eating, it seems natural.

I've been doing NegaMax (mostly) off & on for 15 years. I'm tolerably comfortable with it. (Not as good as you are, but I manage. There are *lots* of better chess programmers than I am. No question about that. But I am reasonable comfortable with recursion & NegaMax.)

That's why I think this draw problem really is a problem. (Well, as big as any draw can cause a problem. If you always win or loose but never draw, then this whole thing is totally irrelevant.)

If a program has only one draw, then it'll do fine. But if it starts having several, then there is nothing to stop it from picking among them at random. (Well, as random as your move ordering is and your time control & hashing will allow.)

Then it's just a matter of hoping the program will pick a move where it can keep seeing the draw later. As long as it can see the draw, it will probably eventually find it. (Aimlessly, which is kind of pathetic, but as long as it can see the draw, it will probably find it.)

If it can't search as deep due to time control or the move ordering methods (hash, etc.) change things enough that it can no longer find the draw in the time alloted, then it has a real problem.

You are still going under the assumption that your program _should_ take the shortest draw. I disagree. In a game vs a human GM, you can find KRPP vs KR positions that are EGTB draws. And the quickest way to draw is to give up both pawns and trade rooks. Do you really want to do that and avoid making the human show you he can draw against your two extra pawns, which is not easy???

This discussion is *NOT* about chosing when to take the draw. That's controled by the offset bias you use. That is an entirely seperate subject.

The point here is that if you do decide to draw, can you find the shortest one that's guaranteed to do it, or will you randomly pick among them and hope your search can still find it until you eventually do draw?

If the program doesn't know that a draw in 1 is better than a draw in 10 or draw in 100 or draw in 200, then why would you expect it to pick the closest (or the one it can be sure of finding next time.)

If for any reason, the search can't find the draw again, then you've lost the draw.

Delaying the draw gives your program more chances to not find it during the next search.

I think you phrased it "Meat makes mistakes". If because you kept delaying the draw, your search can't find it again (time control, move ordering,whatever), you just made that 'meat mistake'.

Just because you found a couple draws on move 38 in 3 minutes doesn't mean you'll be able to find it again on move 39 or 40 in 3 minutes.

After a few delaying moves, you may not even have 3 minutes to spend on finding the draw again. And instead of a draw in 20, because of the delaying moves, it could now be a draw in 22, which could take even more time to find. Time you may not have available to spend.

Your fear that the program is going to see draw and miss it later has no rational basis because usually if it can see a draw in move X then you can expect it also to see the draw in move X+1 because you need less search depth at move X+1.

We do not know what was Coko's problem to find the mate but I suspect that it was simply a bug that caused Coko to believe that there is mate when there was no mate or caused Coko to play too fast.

finding mate at move X and missing it at move X+1 to lose the game is not something that you can normally expect.

Uri

[Carey]

Carey wrote:-

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

If my program at root found and plays bestscore = 0(draw), it seems my opponent will not be able to avoid giving me one. If it converts to a win / loss then one side should have a bug somewhere (???)
Thats why draw_in_33 or draw-in-3 should not matter normally.

Rasjid

It does sure seem that way. But appearances are deceiving.

That assumes that on your next move, you can still find the drawing line.

Don't think about one search but think about several searches during the game.

Assume you just spent your pondering time and your alloted search time, plus a little extra (because it's a hard position) finding a bunch of draws. You have a choice of 10, 12 and 14 moves.

You pick the one that is 14 moves away.

(The numbers are contrived. I know that. But just go with it. Use your own draw-in-xyz moves.)

In your next search you didn't predict his move correctly so the pondering search results aren't valid. You have to search fresh.

This time in those 3 minutes (plus a little extra because its still a hard position), you see the 12 (was 14), and 16 moves away.

One draw is as good as another, so you pick the one 16 moves away. You just happened to find it first.

In your third search, you didn't predict his move correctly, so the pondering search results aren't valid. You have to search fresh.

This time, you don't happen to have a full 3 minutes. You only have 2 minutes. (And you don't have any extra time anymore. You're running low on time.) And that draw that was 16 moves away is below your horizon.

Your search doesn't see it. So by mistake, it picks a move that doesn't draw.

That's the problem. If you keep pushing the draw away, move after move, there's a real chance that you'll no longer see the draw and be force to do a non-drawing move.

In a fixed depth search, or a few test positions, it's not a problem. One draw is as good as another. The problem comes when you are putting these seperate searches together as a sequence of moves in a time controlled game.

The best way to avoid that is to pick a drawing line that you are likely to be able to find next time. That usually means the closest draw.

[Carey]

If you do a draw score of zero, then the program can not tell the difference between a draw in 3 moves from a draw in 33 moves.

I don't understand your problem. What do you mean by 'draw in N moves'? That you can convert to KK on the Nth move? Why would you care if you do that quickly or slowly, say, from KRKR? Or do you also consider KRKR a draw?

At this point in my programming, I am more concerned about the actual draw itself. Stalemate, repetition, 50 move rule. The end result.

For conversion to an eventual draw... I don't really know.

I don't approve of tablebases, so I'm not converned with that. I would guess that I would consider a result from there an exact score (draw or mate), because I could always find the position there. No risk of later searches missing it.

For conversion to draw... I guess that would depend on how confident I would be of my program being able to figure things out later. Not a good answer, but at this point I don't know.

Not all draws are equal. KBPPKB can be a draw with unlike Bishops. So is KKB. But if you have the choice between converting to KBPPKB or KKB, the former is infinitely preferable. Even if you know it is a draw, your opponent might not know, and bungle it. In the second case there is no chance on that.

You definetly have a point. Not all draws are equal. I guess that would be a part of the draw bias. Where I would put the draw into the eval score.

But I don't really know at this point. And I'm not going to be using tablebases, so I don't have to worry about those complications.

I guess I'd have to assume that my opponent is a lot better at chess than my program is, so if my program thinks it's down (too complicated ending, material down, whatever), it should probably try to draw.

So it is a bad idea to score draws as zero. Of course you want to prevent KNK from scoring +3, so that the engine will prefer it to KPPK. But it is better to simply divide the score of such recognized draws by 5 or so, so that the natural ranking of "draws I am lucky to have" vs "draws that upset me" is preserved.

I think this is starting to get into some of the articles I've read about exact vs. inexact scores.

Some scores are more trustworthy than others. Some scores are more likely than others, even if they have the same value.

Those are a little bit beyond me.

The problem of how much in a hurry you are to reach a position, is a general one, that is not any different for draws than in any other case. It depends on how much better or worse that position is than your current position. If it is better, you don't want to delay going there unnecessarily. If it is worse, you try to delay going there as much as possible, in the hope the opponent will bungle it, or some miracle cure reveals itself just over the horizon, by the time you get close to what now seems inescapable, and can look further ahead.

Right so far.

Even if you would argue that theoretical draws like KK or KBK have exact scores, this is of no importance, as usually the score of the alternatives (including current position) will not be exact. So it remains chosing a move in the face of uncertain evaluation of end leaves.

The thread on delayed-loss bonus addresses that problem. Not everyone is convinced, though, that it is worth anything to hurry up improving your position. I would say it is, but I have not done quantitative measurements on this. (My computer is currently busy finding more precise piece values for normal and fairy pieces...)

I haven't followed that thread.

A lot of the threads in this forum are a bit hard for me to follow.

Especially very long threads objective testing, etc., and their spin-off threads. I was interested in those threads for a few pages, but they got way too long and convoluted for me.

Point is, I didn't notice the delayed loss thread and I'm not so sure that what I was discussing would be the same.

My focus was on simply telling the difference between a draw in 4 from a draw in 3 or 5, and being able to pick the shortest one, instead of randomly picking among them.

[Uri Blass]

Carey wrote:-

Here's how going towards "_any_ draw" causes the problem:

You make a move towards a draw of some sort. The opponent doesn't reply as expected so you have to search instead of using your saved move line.

If my program at root found and plays bestscore = 0(draw), it seems my opponent will not be able to avoid giving me one. If it converts to a win / loss then one side should have a bug somewhere (???)
Thats why draw_in_33 or draw-in-3 should not matter normally.

Rasjid

It does sure seem that way. But appearances are deceiving.

That assumes that on your next move, you can still find the drawing line.

Don't think about one search but think about several searches during the game.

Assume you just spent your pondering time and your alloted search time, plus a little extra (because it's a hard position) finding a bunch of draws. You have a choice of 10, 12 and 14 moves.

You pick the one that is 14 moves away.

(The numbers are contrived. I know that. But just go with it. Use your own draw-in-xyz moves.)

In your next search you didn't predict his move correctly so the pondering search results aren't valid. You have to search fresh.

This time in those 3 minutes (plus a little extra because its still a hard position), you see the 12 (was 14), and 16 moves away.

One draw is as good as another, so you pick the one 16 moves away. You just happened to find it first.

In your third search, you didn't predict his move correctly, so the pondering search results aren't valid. You have to search fresh.

This time, you don't happen to have a full 3 minutes. You only have 2 minutes. (And you don't have any extra time anymore. You're running low on time.) And that draw that was 16 moves away is below your horizon.

Your search doesn't see it. So by mistake, it picks a move that doesn't draw.

That's the problem. If you keep pushing the draw away, move after move, there's a real chance that you'll no longer see the draw and be force to do a non-drawing move.

In a fixed depth search, or a few test positions, it's not a problem. One draw is as good as another. The problem comes when you are putting these seperate searches together as a sequence of moves in a time controlled game.

The best way to avoid that is to pick a drawing line that you are likely to be able to find next time. That usually means the closest draw.

I think that you care too much about hypotetical case that never happens in practice based on my experience.

If you are in worse position then
In most cases you are going to see the faster draw first.

Considering the fact that you do not even use hash tables then the only way not to see the fastest draw first is because of some extensions or pruning and I cannot see it happens again and again.

Cases when you see a draw and miss it later may happen but it should be rare and they may happen also if you prefer faster draws(you can see draw in 18 plies that is the shortest draw after long ponder on the opponent move and after your opponent move miss draw in 16 plies because you have no time to finish 16 plies)
I see no reason to care about something that may happen in 1 out of 1000 games.

You have better ways to try to improve your program and I suggest that you simply return 0 for draws.

Uri