3 Champs Highlights

[Lyudmil Tsvetkov]

Hi,

I have no insights into Komodos eval but if he would consider a White pawn at g5 in this position good it would have no trouble finding g4 even if the bonus is not applied with a pawn on the 4th rank already. That is how search works.

In my engines eval I award a bonus for a pawn storm mainly in positions where the kings have castled to opposite sides.

So I discourage pawns from advancing if they are part of the own king shelter. If the penalty for a weaker shelter is higher than the bonus for a storming pawn the pawn will not be moved.

Hi Thomas.

To ask a question in a Henk-van-den-Beltian manner, are you sure that if a bonus is not applied with a storming pawn on the 4th rank, the search will always necessarily find the g4-g5 advance, if a storming pawn on g5 is considered good? Probably a layman's question, but I have to ask it.

That is the trick, how could you see that g4 is good at ply 1, when you probably need some 10 plies more to see that the enemy king safety will suffer even worse because of the attacking pawn, and thus its push be justified? I think you can safely dispense bonus points for all storming pawns constituting part of the king shelter, whenever the opponent does not have any visible counterplay; or when, according to your own eval, for a series of moves (say 5 consecutive), you have a good positive eval, but it does not increase, meaning you are not finding the right way. So then you can risk, as the risk might bring you dividends. I think theory of sacrifices might very well run along the same lines: you have a good positive score, you do not increase it for a number of consecutive moves, and therefore you attempt a sacrifice, which should have decent chances of success, as when your eval score is real, there must be a way to increase it even further.

As opposite-side castlings occur pretty rarely, I think iCE (why I am tempted to write ice or Ice instead? ) could well miss many realistic opportunities to win a game by using its storming pawns that still belong to the king shelter. I think whenever you have the initiative (meaning leading in score), it is important to attack, for otherwise you miss the initiative (positive score). How do I know that g4 is good at ply 1? I do not know, I see it is winning a couple of plies later, and my experience tells me white is not in any real danger, even if it does not have any pawns to shelter the king. But I do not know about engines, maybe you should experiment, within the limits of programming you know much better, with different options for storming pawns. I think an agressive one (scoring high such pawns) would do well in most cases, when you have a sufficient plus in score (30-40cps), but do not find a way to increase it.

Thanks again for informing me how storming works in some engines, I was really clueless.

And please excuse me for any inaccuracies/funny things I have suggested.

[Lyudmil Tsvetkov]

This might be a bit off-topic, but, as I am observing very frequently such a behaviour, I decided to raise the issue.

[d]8/3b4/5kpp/8/6P1/4P3/4B3/4K3 w - - 0 67
This is a position from the 53rd game, pitting Komodo with white against Houdini. The position is obviously a draw, no possibilities whatever for a win for one of the sides, but both players trudge on heroically with this endgame for 40 more moves until finally, exhausted by the fervent battle, they agree to a draw at move 106.

[d]4b3/8/7K/8/6B1/4P3/3k4/8 b - - 0 106

Here the engines agree to a draw.

My question to all forumers, experts, possibly authors, is whether such a rather consistent behaviour of leading and non-leading engines is necessary and justified. Of course, I understand there are positions in which you should press on, but there are also some very simple, very obviously drawish positions whose martyrisation could very well be avoided.

It is really a pity, especially for the public watching the event, that some meaningless shuffling should become the center-piece of attention for quite some time. I could even call it the Ponomaryov syndrome, playing until your last pawn, but I think it is even worse than that, because modern engines are supposed to be very sophisticated, and they indeed are in a wide range of fields; however, for me, here they fail. It is not very much grandmasterly at all, really, to observe such a behaviour or be the mastermind behind it.

Any suggestions what could be done to avoid similar behaviour of engines?

Best, Lyudmil

Very often both programs KNOW it's a draw but there is no provision in most chess software for 2 programs to agree to a draw between themselves. You would have to be able to propose and also accept or reject the proposal. So humans often make the adjudication decisions. Such a protocol thing could be added and it would help in some of these positions. (**) Why would you expect a computer to stop playing without being instructed to stop?

Even if such a protocol was instituted there are clearly some positions which computers do not understand to the point of knowing it's a dead draw. They might play them correctly but not understand. That is because at the current time chess programs do not do chains of reasoning like humans do. For example a computer will never reason like this:

1. I cannot win because I have only a knight
2. My opponent has a knight and pawn.
3. I cannot hope to win, only draw.
4. I must stop that pawn and it's ok to SAC my knight to do it

Most programs KNOW that a lone knight is a draw so they will SAC their knight in this situation, but not because they reasoned it out like the above - only because they were given a rule about the specific values of the configurations.

Bishop of opposite color when trivially drawn is easy to spot because a human can sweep the board with his eyes and apply a "general case" to potentially dozens of positions. Computers simply cannot do that - or at least cannot do that now. So we just tell them that if you have bishops of opposite color the advantage of an extra pawn or two is LESS. We cannot even reliably specify exactly when it's a draw and when it's not.

Another example is locked pawn draws. You can be up a queen and a win is impossible and a human can see this at a glance. It's actually more non-trivial than you think to create rules which cover situations that are intuitive to a human and never go wrong. For example determining if a locked pawn is a draw is possible but you have to cover a bunch of things such as can something like a knight pass to the opponent side? Is a sacrifice possible to break the lock? Even knowing which side of the locked pawn structure a piece is has to be explicitly coded even though humans see it at a glance. It's not as simple as just saying, "on the opponents half of the board." Sometimes there are holes (the pawns are rammed but not connected) but a king still cannot pass through - or maybe it can and it's still an obvious draw - so all of these cases have to be explicitly coded.

So even the relatively simple case of fully locked pawns - is only "relatively" simple, requiring several checks to avoid being pathologically wrong. And then it comes down to whether it is a true benefit. There will be a speed penalty for any knowledge added. I made a rule that said if there are 8 pawns and they are locked together AND also connected then consider the position very drawish (multiple the score by something like 0.10
or so) and after 50,000 games it came out slightly weaker. This is such a rare corner case that it was not measurable - and perhaps it was even wrong in some cases. However it WAS able to solve positions like QxP (giving up the queen) to break open the pawn structure when it was ahead in material. It LOOKED very impressive in hand-picked situations.

In some ways you remind me of the early days of computer chess, it's like you are noticing things for the first time that seem like major insights to you but we knew about 30 years ago. That's ok - we have never stopped thinking about them and we still listen on the off chance that you will propose a solution instead of just reiterating the problem. We know the problem, please give us a solution.

Thanks Don, for the comment.
Whenever something looks ugly, like playing for 100 moves in a dead drawn endgame, then it is most certainly if not wrong, than at least not perfect.

My suggestion for avoiding dull drawish positions might run somewhere along the following lines:

- both sides have only 2 pawns or less
- score is within the range 0.0-0.40
- both sides have only 2 minor pieces at most, or one rook at most, or just a queen,

then a draw agreement should follow very soon, probably in a couple of moves' time, if none of the above factors changes in the meantime.

This might be just a start, and then, whenever both engines' scores comply with the above requirement, a specific protocol might adjudicate the game as a draw, whenever the above conditions persist for a series of, say, 5 consecutive moves. I think it is very simple, and doable.

Think also about the amount of time you will save for testing purposes, concentrating on meaningful positions instead.

[Don]

Hi,

I have no insights into Komodos eval but if he would consider a White pawn at g5 in this position good it would have no trouble finding g4 even if the bonus is not applied with a pawn on the 4th rank already. That is how search works.

In my engines eval I award a bonus for a pawn storm mainly in positions where the kings have castled to opposite sides.

So I discourage pawns from advancing if they are part of the own king shelter. If the penalty for a weaker shelter is higher than the bonus for a storming pawn the pawn will not be moved.

Hi Thomas.

To ask a question in a Henk-van-den-Beltian manner, are you sure that if a bonus is not applied with a storming pawn on the 4th rank, the search will always necessarily find the g4-g5 advance, if a storming pawn on g5 is considered good? Probably a layman's question, but I have to ask it.

That is the trick, how could you see that g4 is good at ply 1, when you probably need some 10 plies more to see that the enemy king safety will suffer even worse because of the attacking pawn, and thus its push be justified? I think you can safely dispense bonus points for all storming pawns constituting part of the king shelter, whenever the opponent does not have any visible counterplay; or when, according to your own eval, for a series of moves (say 5 consecutive), you have a good positive eval, but it does not increase, meaning you are not finding the right way. So then you can risk, as the risk might bring you dividends. I think theory of sacrifices might very well run along the same lines: you have a good positive score, you do not increase it for a number of consecutive moves, and therefore you attempt a sacrifice, which should have decent chances of success, as when your eval score is real, there must be a way to increase it even further.

As opposite-side castlings occur pretty rarely, I think iCE (why I am tempted to write ice or Ice instead? ) could well miss many realistic opportunities to win a game by using its storming pawns that still belong to the king shelter. I think whenever you have the initiative (meaning leading in score), it is important to attack, for otherwise you miss the initiative (positive score). How do I know that g4 is good at ply 1? I do not know, I see it is winning a couple of plies later, and my experience tells me white is not in any real danger, even if it does not have any pawns to shelter the king. But I do not know about engines, maybe you should experiment, within the limits of programming you know much better, with different options for storming pawns. I think an agressive one (scoring high such pawns) would do well in most cases, when you have a sufficient plus in score (30-40cps), but do not find a way to increase it.

Thanks again for informing me how storming works in some engines, I was really clueless.

And please excuse me for any inaccuracies/funny things I have suggested.

I am unhappy with Komodo's pawn storm code but in practice it actually works really well (compared to not having it.) It is basically a bonus for pushing pawns at the opponent king. If the friendly king is on the same wing it works against king safety. So all other things being equal it will not push a little unless it can push a lot. And it won't push at all if it see's it's own king becomes distressed due to king safety - unless of course it's doing more damage to the opponents king. When kings are on opposite wings of course the issues are not as much in conflict.

There are a number of improvements that are on our list to do to improve pawn storming because it's a huge part of chess. As you recently observed we sometimes end up with a very advanced pawn that FAILED to do its job properly (opening up a file) and it's a little embarrassing to see that. We have some ideas for improving that.

For any of you new chess programmers I have some advice about tuning evaluation. In general you will never get good balance if you don't tune in a very incremental way. Sometimes Larry will notice that in some middlegame position Komodo will over-estimate the advantage of one side or even get it backwards. Let's say that it seems to be off by full half a pawn - for example there are some middlegames theory says gives white only a small edge, but most programs give half a pawn or more. After some analysis you decide that mobility is too high and simple slightly backward pawns are penalized too severely. The temptation is to make huge adjustments to "fix" the position in question - but chances are that you cannot fix it with a simple band-aid or weight adjustment. If you can make a small but sensible adjustment and change the 50 to a 45 you have done a LOT.

Sometimes we will test 4 or 5 different values - and we will not always made the adjustment that tested best if we see a serious point of diminishing returns. First of all there will be a great deal of noise in the test anyway - so we will tend to pick the smallest change that accomplishes most of the benefit. It's like adjusting the thermostat in a home - some people get a little cold and crank the heat up 20 degrees when it only needs a minor adjustment and then 30 minutes later they have to make another big adjustment.

[Don]

This might be a bit off-topic, but, as I am observing very frequently such a behaviour, I decided to raise the issue.

[d]8/3b4/5kpp/8/6P1/4P3/4B3/4K3 w - - 0 67
This is a position from the 53rd game, pitting Komodo with white against Houdini. The position is obviously a draw, no possibilities whatever for a win for one of the sides, but both players trudge on heroically with this endgame for 40 more moves until finally, exhausted by the fervent battle, they agree to a draw at move 106.

[d]4b3/8/7K/8/6B1/4P3/3k4/8 b - - 0 106

Here the engines agree to a draw.

My question to all forumers, experts, possibly authors, is whether such a rather consistent behaviour of leading and non-leading engines is necessary and justified. Of course, I understand there are positions in which you should press on, but there are also some very simple, very obviously drawish positions whose martyrisation could very well be avoided.

It is really a pity, especially for the public watching the event, that some meaningless shuffling should become the center-piece of attention for quite some time. I could even call it the Ponomaryov syndrome, playing until your last pawn, but I think it is even worse than that, because modern engines are supposed to be very sophisticated, and they indeed are in a wide range of fields; however, for me, here they fail. It is not very much grandmasterly at all, really, to observe such a behaviour or be the mastermind behind it.

Any suggestions what could be done to avoid similar behaviour of engines?

Best, Lyudmil

Very often both programs KNOW it's a draw but there is no provision in most chess software for 2 programs to agree to a draw between themselves. You would have to be able to propose and also accept or reject the proposal. So humans often make the adjudication decisions. Such a protocol thing could be added and it would help in some of these positions. (**) Why would you expect a computer to stop playing without being instructed to stop?

Even if such a protocol was instituted there are clearly some positions which computers do not understand to the point of knowing it's a dead draw. They might play them correctly but not understand. That is because at the current time chess programs do not do chains of reasoning like humans do. For example a computer will never reason like this:

1. I cannot win because I have only a knight
2. My opponent has a knight and pawn.
3. I cannot hope to win, only draw.
4. I must stop that pawn and it's ok to SAC my knight to do it

Most programs KNOW that a lone knight is a draw so they will SAC their knight in this situation, but not because they reasoned it out like the above - only because they were given a rule about the specific values of the configurations.

Bishop of opposite color when trivially drawn is easy to spot because a human can sweep the board with his eyes and apply a "general case" to potentially dozens of positions. Computers simply cannot do that - or at least cannot do that now. So we just tell them that if you have bishops of opposite color the advantage of an extra pawn or two is LESS. We cannot even reliably specify exactly when it's a draw and when it's not.

Another example is locked pawn draws. You can be up a queen and a win is impossible and a human can see this at a glance. It's actually more non-trivial than you think to create rules which cover situations that are intuitive to a human and never go wrong. For example determining if a locked pawn is a draw is possible but you have to cover a bunch of things such as can something like a knight pass to the opponent side? Is a sacrifice possible to break the lock? Even knowing which side of the locked pawn structure a piece is has to be explicitly coded even though humans see it at a glance. It's not as simple as just saying, "on the opponents half of the board." Sometimes there are holes (the pawns are rammed but not connected) but a king still cannot pass through - or maybe it can and it's still an obvious draw - so all of these cases have to be explicitly coded.

So even the relatively simple case of fully locked pawns - is only "relatively" simple, requiring several checks to avoid being pathologically wrong. And then it comes down to whether it is a true benefit. There will be a speed penalty for any knowledge added. I made a rule that said if there are 8 pawns and they are locked together AND also connected then consider the position very drawish (multiple the score by something like 0.10
or so) and after 50,000 games it came out slightly weaker. This is such a rare corner case that it was not measurable - and perhaps it was even wrong in some cases. However it WAS able to solve positions like QxP (giving up the queen) to break open the pawn structure when it was ahead in material. It LOOKED very impressive in hand-picked situations.

In some ways you remind me of the early days of computer chess, it's like you are noticing things for the first time that seem like major insights to you but we knew about 30 years ago. That's ok - we have never stopped thinking about them and we still listen on the off chance that you will propose a solution instead of just reiterating the problem. We know the problem, please give us a solution.

Thanks Don, for the comment.
Whenever something looks ugly, like playing for 100 moves in a dead drawn endgame, then it is most certainly if not wrong, than at least not perfect.

My suggestion for avoiding dull drawish positions might run somewhere along the following lines:

- both sides have only 2 pawns or less
- score is within the range 0.0-0.40
- both sides have only 2 minor pieces at most, or one rook at most, or just a queen,

then a draw agreement should follow very soon, probably in a couple of moves' time, if none of the above factors changes in the meantime.

This might be just a start, and then, whenever both engines' scores comply with the above requirement, a specific protocol might adjudicate the game as a draw, whenever the above conditions persist for a series of, say, 5 consecutive moves. I think it is very simple, and doable.

Think also about the amount of time you will save for testing purposes, concentrating on meaningful positions instead.

Most GUI's let you set adjudication rules. You have to first decide whether this is an adjudication situation or a program decision. IN a lot of cases it's not the fault of the programs which already KNOW the position is a draw. You can tell by looking at the scores.

In my opinion the right way to handle this issue is to let the programs decide between themselves - as in human games. If I offer you a draw you have to decide whether to accept it or not and if you do the game can be stopped. I don't think we have such a protocol right now so the computers are going to play out the games even when they both know it's a draw. It would be like human matches if you forbid draw offers.

There is a little trick that could help computers end the games a little bit earlier without a draw agreement protocol however. If the computer recognized that a position is a hopeless draw, you can modify the draw score to be slightly higher than the ending. For example if the ending is scored as zero and a draw is scored as 1, the computer is going to prefer a repetition over shuffling the pieces around. If BOTH programs are designed this way and BOTH recognize that the position is a dead draw these games will very quickly terminate with no help from any GUI adjudication rules.

As far as saving testing time - our solution to this is to play Fischer time control with very small increments. In this way a 120 move game does not take much longer than an 80 move game. It's as if after 60 or 70 moves the rest is just a formality.

[Don]

[d]1r2r1k1/1pn2p1p/2pb1qp1/p4p2/3P4/1QP3P1/PP3PBP/R1B2RK1 w - - 0 17

This is a position from the 57th game of the tournament.

Stockfish has played very well the opening with white against Houdini, but now decides to attack and eat with the queen an enemy pawn far from where the main battle takes place. Stockfish plays now 17.Qa4, upon which Houdini replies with 17...f4, takes the initiative and builds up a devastating king attack.

I think Stockfish could easily keep some edge by playing 17.f4 itself instead, depriving black of any attacking opportunities and using its majority pawn on the queen side, when the time is favourable for that. I think playing 17.f4 is a must in this position, even if black did not threaten with a very menacing attack, because this move would be very helpful in the long term: it fixes (blocks) the most advanced black double pawn (f5) with an own pawn, and that is a serious advantage, long-term at that, that should be worth some 10-15cps. In this way the weakness of the double pawn becomes difficult or almost impossible to straighten, and that is always a positional asset. I think that whenever a real possibility to block with an own pawn the most advanced enemy double pawn exists, such a move should enjoy priority status, because a move or 2 later it could already not be playable, thus missing a valuable positional edge.

Of course, white might have been afraid that f4 would leave the e3 square undefended, but that is much less important in this particular case.

Any engines there willing to play 17.f4?

Best, Lyudmil

Lyudmil,

This is a great example position for us - we do have some trouble with this sort of thing and we are working on something now that may help considerably.

Don

[Don]

[d]1r2r1k1/1pn2p1p/2pb1qp1/p4p2/3P4/1QP3P1/PP3PBP/R1B2RK1 w - - 0 17

This is a position from the 57th game of the tournament.

Stockfish has played very well the opening with white against Houdini, but now decides to attack and eat with the queen an enemy pawn far from where the main battle takes place. Stockfish plays now 17.Qa4, upon which Houdini replies with 17...f4, takes the initiative and builds up a devastating king attack.

I think Stockfish could easily keep some edge by playing 17.f4 itself instead, depriving black of any attacking opportunities and using its majority pawn on the queen side, when the time is favourable for that. I think playing 17.f4 is a must in this position, even if black did not threaten with a very menacing attack, because this move would be very helpful in the long term: it fixes (blocks) the most advanced black double pawn (f5) with an own pawn, and that is a serious advantage, long-term at that, that should be worth some 10-15cps. In this way the weakness of the double pawn becomes difficult or almost impossible to straighten, and that is always a positional asset. I think that whenever a real possibility to block with an own pawn the most advanced enemy double pawn exists, such a move should enjoy priority status, because a move or 2 later it could already not be playable, thus missing a valuable positional edge.

Of course, white might have been afraid that f4 would leave the e3 square undefended, but that is much less important in this particular case.

Any engines there willing to play 17.f4?

Best, Lyudmil

Lyudmil,

This is a great example position for us - we do have some trouble with this sort of thing and we are working on something now that may help considerably.

Don

I'm actually referring to the Houdini Komodo game where Komodo gave away it's possibly winning advantage, not this position.

Don

[Don]

This is the position that I'm referring to.

[d]r1b1r1k1/1pb2q2/2p1pn2/3p3p/PBPPp1p1/1Q2P1P1/P1RNNP1P/5RK1 b - - 0 21

This is a position from the 46th game Stockfish-Komodo.

Stockfish has just played 21.g3 and sees itself in advantage by some 0.74 centipawns, very decisive one, while Komodo thinks it is about equal.

Objectively, I think the position is already won for black, because of the following reasons:

- very weak backward (backward-fated) white pawn on f2, part of the king shelter; that makes the shelter very inflexible and black can gradually concentrate attacking resources
- 2 weak squares on the 3rd rank, part of the king shelter (f3 and h3), whereupon different enemy pieces, especially the knight, might intrude
- play is more or less closed, because of the big diagonally connected pawn chains, which gives black sufficient time to prepare a decisive strike

Black has some difficulties with developing its queen side, but I think those could be solved and are less weighty than the above-mentioned serious weaknesses of the white king shelter.

I tell you, I like this position, because it is a bit uncommon and also rich in resources that should be sought out. I could suggest a plan like, for example, Nh7-g5, Kh7, Rh8, Kg8, and only then h4, if necessary, prepare for e5 and bring the a rook in support of the attack, etc. In that case it is difficult to imagine how white could defend.

Komodo, however, proceeds to lose the already won game in just 2 moves by playing h5-h4-h3 instead, closing entirely the side where it is supposed to open files for attack.

[d]r1b1r1k1/1pb2q2/2p1pn2/3p4/PBPPp1p1/Q3P1Pp/P1RNNP1P/5RK1 w - - 0 23

This is the picture 2 moves later, where already white is lost. Black has a single semi-open file at its disposal (f), but both f2 and f3 are well guarded, white can also play Nf4, blocking this file to good avail, etc. It takes Komodo, however, some 60 moves to understand it is losing; and the same amount of moves it takes Stockfish to find a way to finally break through, but it does it in great fashion. When I think about that, it makes me happy that it is not only me that can lose games in 2 moves, but also Komodo can do that. If Komodo can do that, I have the right to do it too

[d]r1b1r1k1/1pb2q2/2p1pn2/3p4/PBPPpNp1/Q3P1Pp/P1RN1P1P/5RK1 b - - 0 23

I think black should have attempted to play e5 here, whatever the result, there is simply no other option.

[d]k1N5/1p4R1/rP2p3/P1PpB2q/PQ2p3/4Pp1p/5P1P/7K b - - 0 101

But I do not like this: a Ponomaryov-style Komodo playing until the very last glimmer of hope.

Finally, let's go back for a while to the main diagram:

[d]r1b1r1k1/1pb2q2/2p1pn2/3p3p/PBPPp1p1/1Q2P1P1/P1RNNP1P/5RK1 b - - 0 21

Komodo played very well until now, both g5 and g4 are great moves, but the point is: how many engines will be able to judge correctly that black has a considerable, probably winning advantage, and to find the correct winning way?

Any distinct engine output on this position very much appreciated.

Best, Lyudmil

[Lyudmil Tsvetkov]

This might be a bit off-topic, but, as I am observing very frequently such a behaviour, I decided to raise the issue.

[d]8/3b4/5kpp/8/6P1/4P3/4B3/4K3 w - - 0 67
This is a position from the 53rd game, pitting Komodo with white against Houdini. The position is obviously a draw, no possibilities whatever for a win for one of the sides, but both players trudge on heroically with this endgame for 40 more moves until finally, exhausted by the fervent battle, they agree to a draw at move 106.

[d]4b3/8/7K/8/6B1/4P3/3k4/8 b - - 0 106

Here the engines agree to a draw.

My question to all forumers, experts, possibly authors, is whether such a rather consistent behaviour of leading and non-leading engines is necessary and justified. Of course, I understand there are positions in which you should press on, but there are also some very simple, very obviously drawish positions whose martyrisation could very well be avoided.

It is really a pity, especially for the public watching the event, that some meaningless shuffling should become the center-piece of attention for quite some time. I could even call it the Ponomaryov syndrome, playing until your last pawn, but I think it is even worse than that, because modern engines are supposed to be very sophisticated, and they indeed are in a wide range of fields; however, for me, here they fail. It is not very much grandmasterly at all, really, to observe such a behaviour or be the mastermind behind it.

Any suggestions what could be done to avoid similar behaviour of engines?

Best, Lyudmil

Very often both programs KNOW it's a draw but there is no provision in most chess software for 2 programs to agree to a draw between themselves. You would have to be able to propose and also accept or reject the proposal. So humans often make the adjudication decisions. Such a protocol thing could be added and it would help in some of these positions. (**) Why would you expect a computer to stop playing without being instructed to stop?

Even if such a protocol was instituted there are clearly some positions which computers do not understand to the point of knowing it's a dead draw. They might play them correctly but not understand. That is because at the current time chess programs do not do chains of reasoning like humans do. For example a computer will never reason like this:

1. I cannot win because I have only a knight
2. My opponent has a knight and pawn.
3. I cannot hope to win, only draw.
4. I must stop that pawn and it's ok to SAC my knight to do it

Most programs KNOW that a lone knight is a draw so they will SAC their knight in this situation, but not because they reasoned it out like the above - only because they were given a rule about the specific values of the configurations.

Bishop of opposite color when trivially drawn is easy to spot because a human can sweep the board with his eyes and apply a "general case" to potentially dozens of positions. Computers simply cannot do that - or at least cannot do that now. So we just tell them that if you have bishops of opposite color the advantage of an extra pawn or two is LESS. We cannot even reliably specify exactly when it's a draw and when it's not.

Another example is locked pawn draws. You can be up a queen and a win is impossible and a human can see this at a glance. It's actually more non-trivial than you think to create rules which cover situations that are intuitive to a human and never go wrong. For example determining if a locked pawn is a draw is possible but you have to cover a bunch of things such as can something like a knight pass to the opponent side? Is a sacrifice possible to break the lock? Even knowing which side of the locked pawn structure a piece is has to be explicitly coded even though humans see it at a glance. It's not as simple as just saying, "on the opponents half of the board." Sometimes there are holes (the pawns are rammed but not connected) but a king still cannot pass through - or maybe it can and it's still an obvious draw - so all of these cases have to be explicitly coded.

So even the relatively simple case of fully locked pawns - is only "relatively" simple, requiring several checks to avoid being pathologically wrong. And then it comes down to whether it is a true benefit. There will be a speed penalty for any knowledge added. I made a rule that said if there are 8 pawns and they are locked together AND also connected then consider the position very drawish (multiple the score by something like 0.10
or so) and after 50,000 games it came out slightly weaker. This is such a rare corner case that it was not measurable - and perhaps it was even wrong in some cases. However it WAS able to solve positions like QxP (giving up the queen) to break open the pawn structure when it was ahead in material. It LOOKED very impressive in hand-picked situations.

In some ways you remind me of the early days of computer chess, it's like you are noticing things for the first time that seem like major insights to you but we knew about 30 years ago. That's ok - we have never stopped thinking about them and we still listen on the off chance that you will propose a solution instead of just reiterating the problem. We know the problem, please give us a solution.

Thanks Don, for the comment.
Whenever something looks ugly, like playing for 100 moves in a dead drawn endgame, then it is most certainly if not wrong, than at least not perfect.

My suggestion for avoiding dull drawish positions might run somewhere along the following lines:

- both sides have only 2 pawns or less
- score is within the range 0.0-0.40
- both sides have only 2 minor pieces at most, or one rook at most, or just a queen,

then a draw agreement should follow very soon, probably in a couple of moves' time, if none of the above factors changes in the meantime.

This might be just a start, and then, whenever both engines' scores comply with the above requirement, a specific protocol might adjudicate the game as a draw, whenever the above conditions persist for a series of, say, 5 consecutive moves. I think it is very simple, and doable.

Think also about the amount of time you will save for testing purposes, concentrating on meaningful positions instead.

Most GUI's let you set adjudication rules. You have to first decide whether this is an adjudication situation or a program decision. IN a lot of cases it's not the fault of the programs which already KNOW the position is a draw. You can tell by looking at the scores.

In my opinion the right way to handle this issue is to let the programs decide between themselves - as in human games. If I offer you a draw you have to decide whether to accept it or not and if you do the game can be stopped. I don't think we have such a protocol right now so the computers are going to play out the games even when they both know it's a draw. It would be like human matches if you forbid draw offers.

There is a little trick that could help computers end the games a little bit earlier without a draw agreement protocol however. If the computer recognized that a position is a hopeless draw, you can modify the draw score to be slightly higher than the ending. For example if the ending is scored as zero and a draw is scored as 1, the computer is going to prefer a repetition over shuffling the pieces around. If BOTH programs are designed this way and BOTH recognize that the position is a dead draw these games will very quickly terminate with no help from any GUI adjudication rules.

As far as saving testing time - our solution to this is to play Fischer time control with very small increments. In this way a 120 move game does not take much longer than an 80 move game. It's as if after 60 or 70 moves the rest is just a formality.

I would agree with both solutions: the protocol one, and the engine-empowered one, as long as the issue is solved. It is indeed a pain for most normally advanced human players to follow such endings.

But I would not go as far as allowing an engine to offer and accept draws in rich positions with a lot of material, except when they are obvious draws, like for example totally locked. In distinction to humans, that need some rest from time to time, and therefore should be allowed to offer draws more or less at will, computers have enough resources of stamina to prolong the fight until it is very clear; and they should do that, as long as it is meaningful to continue playing.

Concerning the timed potentially saved, a single fast game costs you nothing, but what about 30 000 fast games? In 10 000 of those at least 1/3 of the moves will be completely unnecessary.

[Lyudmil Tsvetkov]

[d]1r2r1k1/1pn2p1p/2pb1qp1/p4p2/3P4/1QP3P1/PP3PBP/R1B2RK1 w - - 0 17

This is a position from the 57th game of the tournament.

Stockfish has played very well the opening with white against Houdini, but now decides to attack and eat with the queen an enemy pawn far from where the main battle takes place. Stockfish plays now 17.Qa4, upon which Houdini replies with 17...f4, takes the initiative and builds up a devastating king attack.

I think Stockfish could easily keep some edge by playing 17.f4 itself instead, depriving black of any attacking opportunities and using its majority pawn on the queen side, when the time is favourable for that. I think playing 17.f4 is a must in this position, even if black did not threaten with a very menacing attack, because this move would be very helpful in the long term: it fixes (blocks) the most advanced black double pawn (f5) with an own pawn, and that is a serious advantage, long-term at that, that should be worth some 10-15cps. In this way the weakness of the double pawn becomes difficult or almost impossible to straighten, and that is always a positional asset. I think that whenever a real possibility to block with an own pawn the most advanced enemy double pawn exists, such a move should enjoy priority status, because a move or 2 later it could already not be playable, thus missing a valuable positional edge.

Of course, white might have been afraid that f4 would leave the e3 square undefended, but that is much less important in this particular case.

Any engines there willing to play 17.f4?

Best, Lyudmil

Lyudmil,

This is a great example position for us - we do have some trouble with this sort of thing and we are working on something now that may help considerably.

Don

Thanks Don, but I am under the impression that of all engines I know, Komodo knows this particular rule best. I do not know how you have done this, but Komodo seems to be very expert in handling such positions.

[Lyudmil Tsvetkov]

[d]1r2r1k1/1pn2p1p/2pb1qp1/p4p2/3P4/1QP3P1/PP3PBP/R1B2RK1 w - - 0 17

This is a position from the 57th game of the tournament.

Stockfish has played very well the opening with white against Houdini, but now decides to attack and eat with the queen an enemy pawn far from where the main battle takes place. Stockfish plays now 17.Qa4, upon which Houdini replies with 17...f4, takes the initiative and builds up a devastating king attack.

I think Stockfish could easily keep some edge by playing 17.f4 itself instead, depriving black of any attacking opportunities and using its majority pawn on the queen side, when the time is favourable for that. I think playing 17.f4 is a must in this position, even if black did not threaten with a very menacing attack, because this move would be very helpful in the long term: it fixes (blocks) the most advanced black double pawn (f5) with an own pawn, and that is a serious advantage, long-term at that, that should be worth some 10-15cps. In this way the weakness of the double pawn becomes difficult or almost impossible to straighten, and that is always a positional asset. I think that whenever a real possibility to block with an own pawn the most advanced enemy double pawn exists, such a move should enjoy priority status, because a move or 2 later it could already not be playable, thus missing a valuable positional edge.

Of course, white might have been afraid that f4 would leave the e3 square undefended, but that is much less important in this particular case.

Any engines there willing to play 17.f4?

Best, Lyudmil

Lyudmil,

This is a great example position for us - we do have some trouble with this sort of thing and we are working on something now that may help considerably.

Don

I'm actually referring to the Houdini Komodo game where Komodo gave away it's possibly winning advantage, not this position.

Don

Hi Don, thanks a lot.

I knew that someone would actually save this thread by posting a reply, and you posted in every subthread! I will never forget that.

If you allow me a further question, to which Houdini-Komodo game specifically do you refer?