Binders

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 10:41 am

Re: Binders

Post by Lyudmil Tsvetkov » Fri Feb 06, 2015 11:21 pm

Evert wrote:
Lyudmil Tsvetkov wrote: Very difficult question.

It is a matter of tuning of eval and search terms.
I suspect it's probably more complicated than that. It is sufficient to just add the evaluation term if aiming for a position with that term makes you statistically more likely to find a way to make progress. If it doesn't, it just leads to a dead-end and doesn't help to add Elo.

Let me clarify where I'm coming from. We'll need to make an excursion into chess-variant territory, specifically Shogi.

In Shogi, an important strategy is to build a castle for the king. There are a number of ways to do this, and several different strategies to attack different castle formations. My chess variant program plays Shogi, but it knows nothing about building good castles, it just tries to defend the area around its king as best it can.

Here's where it gets interesting: HGM once told me that strong Shogi programs will build "proper" castles, and will follow the correct strategy to attack (and dismantle) properly build castles. However, if you don't build a proper castle, they will penalise you for doing a shoddy job (by giving themselves a healthy positional bonus), and subsequently fail to exploit that weakness effectively. In other words, they have an evaluation term that tells them that their position is better, but they lack an evaluation term that allows them to make progress.

Now, Chess is not Shogi, in a way chess is far more material driven: if you can eventually win a piece, or simplify the game, the trading gradient will indicate that you have made progress to winning the game. Nevertheless, a similar situation can occur.

Two examples: if you award a bonus for having a passed pawn, but not for advancing it, the program will produce passed pawns and tries to hang on to them, but it will not advance them unless it can find a promotion within the search horizon.
Second example: if an engine doesn't know how to make progress in KBNK, it will not find the mate. Even KRK is difficult to win if you don't know to drive the lone king to a corner.
So far none of the strictly positional eval features I have suggested has passed successful tests and been implemented, as far as I know.
Neither backward-fated pawns, nor apex pawns, nor bimders, nor KID structures, nor using the knowledge of existing closed sides on the board.

But those are the real positional elements that all top human grandmasters possess, and even only stronger players.
They are long-term elements and are a vital feature of high-quality chess.
Right, which could have to do with the point I made above: it's not enough to have a term that tells the engine that a particular positional feature is good or bad, it also needs to have the knowledge to help it make progress.

So perhaps your ideas would be more successful if you could add something from that angle? In other words: I suspect the problem you cite with play in closed positions is that you need to formulate an evaluation term that allows the engine to make progress in a closed position, rather than just terms that allows it to evaluate it more accurately.
I can not add much more about binders: below is a game I just played against latest SF 6.
Perhaps you could annotate the game and indicate what you do to make progress?
Nothing more to add, just look carefully at the game and how the respective binds mainly brought white the victory.
You're more qualified to do that than I am, I'm afraid.
The point is that I do nothing special to make progress, just the usual routine any engine would follow under normal circumstances.

The key is that the existing binds upon vital squares prevent the opponent from having adequate counterplay. So I use the available time while the opponent shuffles or makes useless moves to develop more attack, just that.

There is an e5 bind, I put my knight there, on an active square, just like any engine would do. The point is that, as the knight is defended twice, this is a stronghold, and any capture would lead to the square still remaining a stronghold.

There is an f6 bind, I use the fact that the 2 white g5 and e5 binders prevent black to break free with f7-f5, so black just does not have counterplay where it should, and bring 2 more rooks to attack the king. Absolutely the usual stuff: just bring more attackers to attack the king, something any engine would do and see.

And of course, using existing binds, I push more pawns to attack the king, something any respectable engine would do. Absolutely the usual stuff.

So nothing special here, it is just that the existing binds (that is why they are called binds, because they bind you) prevent the opponent from having sufficient and timely counterplay.

So this is a bit in the vein of prophylaxis, but engines do not seem to be very prophylactic, do they?

Again, I say the problem is not to see how progress is made, you see it and achieve it in the usual way, by strengthening pawn storms and piece attacks and by improving your mobility and psqt, but to have your eval and search terms tuned as whole with the respective new eval terms.

For me, a new term, especially if a bit non-standard, should always be tuned as a whole with all existing search terms. I am quite certain that is the main problem, though I am just a layman.

When I play SF, I observe this very peculiar phenomenon: SF extremely easily sees some quite difficult and complex mates, following a certain pattern, and fully fails to notice other, much less complex mates, that however follow a different pattern.

So this is a problem of approach, SF, as any other engine, is biassed, it sees only what its hard-coded patterns allow it to see, only what its search and eval patterns would suggest. It ignores the rest, thinking it is unimportant, but that might not be the case.

So you introduce a new, strange-looking, positional eval term, test it desperately, as you maybe find it a bit interesting, and it never works, but really never.

Then you also decide to change some search parameters that might influence the behaviour of the new eval term, and ..., oh, God, suddenly it works!

But maybe you will have to change a whole lot of search parameters before you have even the slightest success with such positional terms, as the whole seacrh of modern engines (and they more or less follow the same pattern) is tuned to work within the framework of normal/non-positional terms.

kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 3:48 am

Re: Binders

Post by kbhearn » Sat Feb 07, 2015 2:50 am

It's a good concept for a term i think lyudmil, but perhaps your idea for implementation of it might be a little too simplistic for the size of the impact you wish it to have on eval. If it was worth the 0.3 or so as you would like it to be problems such as what evert describes could be very real where at some point the engine just starts shuffling when it HAS the bind. Surely it will recognise to place pieces into weak squares etc but if there's no tactic once pieces are on 'optimum' squares it will be hesitant to change the structure for a different sort of advantage with such a large term favoring keeping it the same.

Accordingly i think the magnitude of the bonus for the bind has to depend on some sort of importance from a variety of other aggravating/mitigating factors.

Is this square being bound the opponent's ONLY potential pawn break? If they have a potential break on the other side of the board it might not matter so much that their break on this side is prevented.

Is it trapping a pawn that really would like to move to let loose another piece?

Is the square usable? (ex: a 'bind' behind the opponent's pawn chain can look very nice with a knight on it, but can also be equally pointless if the side possessing it can't reach that square)

[d]8/8/8/2p5/2PpP3/8/8/8 w - - 0 1

Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 10:41 am

Re: Binders

Post by Lyudmil Tsvetkov » Sat Feb 07, 2015 12:07 pm

kbhearn wrote:It's a good concept for a term i think lyudmil, but perhaps your idea for implementation of it might be a little too simplistic for the size of the impact you wish it to have on eval. If it was worth the 0.3 or so as you would like it to be problems such as what evert describes could be very real where at some point the engine just starts shuffling when it HAS the bind. Surely it will recognise to place pieces into weak squares etc but if there's no tactic once pieces are on 'optimum' squares it will be hesitant to change the structure for a different sort of advantage with such a large term favoring keeping it the same.

Accordingly i think the magnitude of the bonus for the bind has to depend on some sort of importance from a variety of other aggravating/mitigating factors.

Is this square being bound the opponent's ONLY potential pawn break? If they have a potential break on the other side of the board it might not matter so much that their break on this side is prevented.

Is it trapping a pawn that really would like to move to let loose another piece?

Is the square usable? (ex: a 'bind' behind the opponent's pawn chain can look very nice with a knight on it, but can also be equally pointless if the side possessing it can't reach that square)

[d]8/8/8/2p5/2PpP3/8/8/8 w - - 0 1
Precisely to the point: the setup shown on your diagram tends to favour white in the general case, if there is a pawn on d3 for example. (of course, leaving just black with an advanced defended passer makes no sense)

No matter if white places a piece on d5 or not, even better not.
Thats is the typical KID setup reversed.

White having 2 pawns on e4 and c4 means that it has no pawns on e2 or c2, that would be backward, made such by the d4 black pawn, or maybe semi-backward.

So this setup generally means white has no weaknesses.

Nothing changes if we shift the above setup one colum right, with white pawns on d4,e3 and f4, and black pawns on d5 and e4. Although this is more dangerous for white, as the advanced black pawn is closr to the white king, the setup again means white has no weaknesses in the sense of existing backward pawns. Sometimes this could save you the game even with other factors being bad, but not when one of the white pawns is on f2 for example.

Later, if I find the courage, I might post a couple of examples with binds, I do not know if it would make sense.

But again, that will not work in engines, precisely because their mobility is tuned to other factors that would exclude being tuned with such strange factors.
If you would like for this factor to succeed, you should tune simultaneously your mobility values, as well as some search values, but who would like to tune simultaneously a couple of eval and search terms nowadays, when they have to run thousands of games just to check if a single change is good or bad?

I think people willing to tune a lot could succeed even with a bind concept, but who would be that mad to experiment with sweeping changes to only possibly add a couple of elo and detune all other eval and search parameters?

Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 10:41 am

Re: Binders

Post by Lyudmil Tsvetkov » Sat Feb 07, 2015 9:17 pm

Now, very briefly just take the example of a single bind square, let us say the d5 square.

Of course, the bind is the feature that is due the bonus, it is the destination square, and the binders are simple the 2 own pawns controlling/attacking it.

How useful could a d5 bind be?

[d]6k1/8/3p4/2p1p3/2P1P3/8/8/6K1 w - - 0 1

d5 is very useful bind here, as d6 is a backward-fated pawn, very serious weakness.
d4 is also a bind for black, but it is less noticeable, as it lacks the additional pawn feature

[d]6k1/8/2pp4/4p3/2P1P3/8/8/6K1 w - - 0 1
again, d5 is a very useful bind; d6 is simply a backward pawn

[d]6k1/2p5/3p4/4p3/2P1P3/8/8/6K1 w - - 0 1
black can not get more than a backward pawn here

[d]6k1/8/2ppp3/8/2P1P3/8/8/6K1 w - - 0 1
black does not get a backward pawn here by default, but chances are white will be better in the tactical fight for the central d5 square, as white has already advanced, and black must still do this

[d]6k1/8/8/2p1p3/2PpP3/3P4/8/6K1 w - - 0 1
the typical central KID structure with colours reversed
as said, this should favour white; black has very strong pawn on d4, but the white d5 bind is not less stronger.
any squares left behind as weak squares, undefended by pawns, c3 and e3 above, are simply inaccessible usually to the black pieces, as in order to land there, a black knight must go through either b5,d5 or f5, and all those squares are attacked by the c4 and e4 white binders; only piece that could penetrate on those squares is a dark-coloured bishop, but in a closed game even this would be highly unlikely.
so, basically, the c3 and e3 weak squares are not real weaknesses

at the same time, as said, having white pawns on c4 and e4 means that those pawns are not backward, that would be the case if one of them was on c2 for example

That is why this kind of central KID structure is good, although a superficial assessment might notice just the powerful d4 pawn.

[d]6k1/8/2p1p3/8/2P1P3/8/8/6K1 w - - 0 1
now, here is one case where a white bind on d5 is useless, or with a black pawn on c5 or e5; the binders basically do nothing
maybe therefore a further requirement should be that in front of the bind on the same file there must be an enemy pawn, I do not know

In any case, this is just one of several possibilities where the bind concept backfires; the rest seem to be quite acceptable or good

The above cases would be even more true for binds on the 6th rank, so I really do not see how a bind concept could be a wrong one.

Still, it is a matter of tuning and playing style what to prefer, some people prefer having binds, and other prefer not having binds.

I think it is useful, but who knows?

In any case, how this could be tuned in an engine is utterly beyond me.

zamar
Posts: 613
Joined: Sun Jan 18, 2009 6:03 am

Re: Binders

Post by zamar » Sat Feb 07, 2015 9:48 pm

A very interesting proposition.

I'll do a couple of tests, to see if this idea yields anything in practice. I feel this is definitely worth of try. Even a patzer like me knows that a knight on D5 supported by E4 and C4 can be a real nuisance...
Joona Kiiski

zamar
Posts: 613
Joined: Sun Jan 18, 2009 6:03 am

Re: Binders

Post by zamar » Sun Feb 08, 2015 6:43 am

zamar wrote:A very interesting proposition.

I'll do a couple of tests, to see if this idea yields anything in practice. I feel this is definitely worth of try. Even a patzer like me knows that a knight on D5 supported by E4 and C4 can be a real nuisance...
A naive implementation just passed fishtest: Give bonus for pawn binds which control e5, d5, e6 or d6 square...
Joona Kiiski

mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Binders

Post by mcostalba » Sun Feb 08, 2015 9:48 am

zamar wrote: A naive implementation just passed fishtest: Give bonus for pawn binds which control e5, d5, e6 or d6 square...

Congratulations to both Lyudmil and Joona: idea worked !

Joona already opened a pull request and proably will commit it very soon.


It is very difficult that an evaluation idea passes the strict validating tests that we use in SF. Very few ideas, one out of many tens, is confirmed good after test. So this is an important achievement.

Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 10:41 am

Re: Binders

Post by Lyudmil Tsvetkov » Sun Feb 08, 2015 12:06 pm

mcostalba wrote:
zamar wrote: A naive implementation just passed fishtest: Give bonus for pawn binds which control e5, d5, e6 or d6 square...

Congratulations to both Lyudmil and Joona: idea worked !

Joona already opened a pull request and proably will commit it very soon.


It is very difficult that an evaluation idea passes the strict validating tests that we use in SF. Very few ideas, one out of many tens, is confirmed good after test. So this is an important achievement.
Thanks Marco and Joona!

I am sure something went wrong in order for the test to pass.

If you knew how many more reasonable eval terms of positional nature SF needs...

For example, very simple one, definition for advantage when one of the sides on the board, either queen or king side, is fully closed: give some 50cps bonus for the player having at least one pawn into the enemy camp, on the 5th or 6th ranks, if on the other side of the board all files are closed.

For example: all a,b,c,d files on the queen side are with blocked pawns, white has pawn on f5 on the 5th rank on the other, king side, consequently white gets additional eval advantage of some 50cps.

The point is that you can not break and have counterplay on the queen closed side, while the pawn on f5 on the other side of the board gives that player a bigger advantage than usual.

Simply for the fact that the opponent can not get counterplay on the fully closed queen side. Similar to binds, though with a much more powerful effect.

Thanks again!

mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Binders

Post by mcostalba » Sun Feb 08, 2015 12:44 pm

Lyudmil Tsvetkov wrote:
If you knew how many more reasonable eval terms of positional nature SF needs...
A typical mistake when figuring up a new eval term is to assume that you start from a green field. Instead in eval there are _already_ many terms and possibly what you think is already included (perhaps implicitly) in what is already existing.

For instance eval already bonuses advanced pawns, so giving an additional bonus for an advanced pawn seems redundant with what we have (of course only testing will be able to prove it), here I am just using this example to describe a more general approach to eval tweaking.

I am glad that only very few eval terms work (out of the hundreds tested), because it means that engine stays as free as possible of ad-hoc rules that, although from a human point of view are good and makes the different between a patzer and a good chess player, from software point of view are bad because lead to messy and frozen code.

I am very happy when (in very rare cases unfortunately) we end up with a more general term that replaces many small specialized terms: when this happens is a big success for long term maintainability and scaling of SF.

Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 10:41 am

Re: Binders

Post by Lyudmil Tsvetkov » Sun Feb 08, 2015 5:20 pm

mcostalba wrote:
Lyudmil Tsvetkov wrote:
If you knew how many more reasonable eval terms of positional nature SF needs...
A typical mistake when figuring up a new eval term is to assume that you start from a green field. Instead in eval there are _already_ many terms and possibly what you think is already included (perhaps implicitly) in what is already existing.

For instance eval already bonuses advanced pawns, so giving an additional bonus for an advanced pawn seems redundant with what we have (of course only testing will be able to prove it), here I am just using this example to describe a more general approach to eval tweaking.

I am glad that only very few eval terms work (out of the hundreds tested), because it means that engine stays as free as possible of ad-hoc rules that, although from a human point of view are good and makes the different between a patzer and a good chess player, from software point of view are bad because lead to messy and frozen code.

I am very happy when (in very rare cases unfortunately) we end up with a more general term that replaces many small specialized terms: when this happens is a big success for long term maintainability and scaling of SF.
I intuitively understand what you mean, but in order to fully understand, to have the gut feeling, so to say, I must be a programmer myself, and good at that.

Not every programmer has that gut feeling, I suppose.

Tuning is essential, no doubt about that, eval features find repeated patterns in different terms, but according to me specialisation is also important, otherwise how would you get a grasp of the specific?

You have different kinds of advanced pawns, in some positions you encounter one type of such pawns, in others another type, so how will you do finely without specifying?

Marco, please rest assured, long term maintainability and scaling is also a cherished goal of mine. :) (otherwise, how would I play a non-maintainable and non-scaling SF?)

Considering the eval term that I call fully closed side, or just closed side, i.e. a bonus for fully closed side, here is what I meant, maybe someone will find it useful:

As said, you give 50cps bonus or so if one player has a pawn on the 5th rank on either the queen or king side of the board, while the other side of the board is fully closed, i.e. you have 4 blocked pawns on all files there.

Below 3 examples

[d]6k1/8/4p3/3pP3/p1pP4/PpP5/1P6/6K1 w - - 0 1
all 4 files on the queen side, a-d, are with blocked pawns, white has a pawn on the 5th rank into the enemy camp on the other side of the board, e5, you give white 50cps additional bonus

[d]6k1/8/5p2/p1p1pP2/PpPpP3/1P1P4/8/6K1 w - - 0 1
all 4 files on the queen side, a-d, are closed with blocked pawns, white has a pawn into the enemy camp on the 5th rank on the other side of the board, f5, consequently you give white an additional bonus of 50cps; the bonus is for the fact that black does not have counterplay on the queen side

[d]6k1/8/4p1p1/3pPpPp/2pP1P1P/2P5/8/6K1 w - - 0 1
all files on the king side are closed with blocked pawns, e-h files, black has a pawn on the 5th rank into the enemy camp on the other side of the board, c4, consequently you give black an additional bonus of 50cps

Again, this is very similar to the bind concept: the bonus is for the fact that the fully closed side prevents the opponent from having realistic counterplay there. So while the advanced pawn assures you of a good attack, the opponent will suffer because he lacks counterplay. It might take time to show, but it will show.

Speaking of the bind, just as the fully closed side, this is not a pawn feature, but a square feature.

Even though specific, ad-hoc rules might be a wrong aproach in engine programming, or at least from accomplished programmers point of view, I really can not think of a more general feature that could replace that rule. Just because this is very specific.

I think the rule itself is a good one, as it should have no exceptions, or almost no exceptions, in sharp contrast to many other terms you have to tune and retune.

I would be really interested to know if a similar rule is implementable in engines, maybe someone could try it, it will surely fail, but I think is worth a try.

Btw., thanks again for SF 6.
My next download will be SF 7. :)

Post Reply