Lyudmil Tsvetkov wrote:carldaman wrote:Lyudmil Tsvetkov wrote:jorose wrote:Hi, unfortunately I'm on vacation so I don't have time to write longer =(
I was just curious if I understood your point correctly about a pointy pawn chain: A pointy pawn chain is a pawn chain where the end (= defended part) of the chain is near the enemy king?
Fully correct.
Ask Carl about further details.
Well, I also like to stipulate that the defending King be on the shorter (unshielded) side of the board relative to the pointy chain. For example, with a c3-d4-e5-f6/f7-e6-d5 chain, the Black King is just as close to f6 on e8 as it is on g8, but the latter is far less safe since it's on the short, exposed side of the chain (in other words, the chain is pointing
towards the King) - whereas on e8 the King is shielded by the chain itself.
Please note that I like to take into account both the White AND corresponding Black pawns that form the chain (c3-d4-e5-f6/f7-e6-d5 in this example) , which really make up a compound unit together. I prefer the term
diagonal pawn barrier to refer to these chains taken together as one unit.
Hope this distinction all makes sense.
Regards,
CL
Whatever you say, Carl.
You are the authority on pointy chains.
Programmers better listen to you.
The DPB really impresses me and I have the same feeling - it is really a barrier, with one tip being very advantageous, and the other tip useless.
Just to ask you, according to you,
how many years/more probably decades will it take before engines start understanding KID structures and pointy chains?
And also,
how many elo do you think engines could gain by implementing good KID knowledge?
I know you will call me a rat-racer, but still I enjoy strong engines, but also some weaker and stylistically interesting ones.
These questions have been on my mind a lot, Lyudmil. Last year I was even hopeful we were on the threshold of a breakthrough in this area. If you recall, Arjun was going to try to make the pointy chain a feature of king safety, rather than just pawn structure, but I suppose the implementation proved to be a lot harder. All it takes is for a small detail to be askew coding logic-wise and the whole concept can fall apart. I'd like to think that we're only a couple of years away from beginning to conquer this weakness in earnest, but more of a concentrated effort is necessary where repeated refinements can be made.
Personally I would settle for any change that would visibly improve play and evaluation in these types of positions, even if it didn't translate into a net gain overall. I know I'm in a minority when it comes to this type of thinking, but sometimes a strategic step has to be taken backwards so that meaningful progress can be made later on.
Another problem is how much Elo it would bring, even if a patch was successful, and I'm afraid not much,
but this has something to do with the openings currently used in testing. If testing incorporated more KID-like structures, or the book lines were made shorter, an improvement in handling pointy chains could result in significant gains since the engine would then be free to exploit this knowledge and steer the game accordingly. We can see how weak the engines can become if playing without book vs an anti-computer specialist, so there's room for a lot of Elo gains, ultimately.
Unfortunately, the books used for most testing tend to mask the problem top engines have, by making the KID a marginal opening that is fairly rarely used/seen. This fallacy was pointed out by yourself as well, since these KID structures can in fact become commonplace if one of the players (typically the human) is allowed to steer play anyway he sees fit early enough in the game.
Regards,
CL