Lyudmil Tsvetkov wrote:
The main eval factor favouring white here, is the pointed white b2-c3-d4-e5-f6 chain, very long chain, and blocked at that.
While it points towards the black king, the black f7-e6-d5-c4-b3 chain points away from the white king.
That is the main distinction, and, as the chains are both very long and blocked, this brings white an additional advantage of not less than 1-1.5 full pawns.
We already talked too much about pointed chains on this forum, and some authors, like Pawel Koziol for example, even reported they made some progress with that.
Pawel even posted some code, gaining elo in Rodent, in the programming section.
So my question to you is, when are you going to implement the pointed chain concept in SF, Vince?
That is the main reason why SF lost this game.
Btw., to make use of your presence here, could you please ask Stefan to push one last try on long chain inner pawns, with half bonus, 1/16 instead of 1/8?
I tried several times via diferent channels, but no result so far.
The problem is, as you see, that SF has big problems with long and pointed chains.
I don't think you will get another try on inner chains soon. There are sound reasons why trying the same test again and again with speculative changes to scores are frowned upon in the structure, and going down to 1/16 will make the bonus very small. Best wait for the dust to settle.
Re the long blocked chain. I think it's well understood that this structure is very favourable because it (a) constrains the king as I mentioned (b) cuts off defending pieces and (c ) stops counterplay as the queenside and centre are blocked. Moreover, this state of affairs is static, giving the attacking side a lot of time to put his pieces into position.
It would be quite easy to write a piece of code that looked for a long, blocked chain pointing at the opponent's king and give it a large bonus. What you can't predict in advance is what effect this will have in positions that are close but not identical, as the engine will suddenly want to get these sorts of positions. But that won't be enough for as you saw, even when given the White pieces, SF doesn't know how to win the position. Merely knowing that the position *is* good (statically) is only half the picture.
Personally, I think this problem and the related problem of fortress detection is one of recognising when tempo ceases to be crucial. The logic is something like this:
1) If I had 2 or 3 moves in a row here, I would be able to win easily.
2) But wait! the position is such that my opponent can only shuffle his pieces around. So I *do*, in a sense, have 2 or 3 moves in a row.
3) Therefore I should try lines where i "ignore" the opponent's moves (speaking loosely) and see what happens in that circumstance.
In your specific example, the logic would be
1) If I had several moves in a row, Rg1->Rg4->Rh4 is obviously killing
2) The wing and centre are blocked completely; so
3) Let's try Rg1 as a candidate move always, even when other moves appear more obvious.
Not so simple to code, but it's getting closer to how a human treats this sort of position.
BTW You said "SF lost this game" but I haven't seen the full score of the game. Can you post it? Was it from an engine match or against a human/centaur?