Longer chain pawn again

[Lyudmil Tsvetkov]

That is his current attempt that jsut failed (we lost the final match )

I meant same as above, but /16

Lyudmil, can you ask him on github to possibly push such a patch.
Temporarily, I do not have/remember my password for there.

I should probably renew my password there, but, having a bit of experience from lst year, I know it is no good to bother the programmers.

They usually know best, push some preliminary tests, etc.

Anyway, would be grateful if you could ask him.

It is a matter of implementation, so that redundancies are avoided.
A couple of attempts might fail, but the term itself is useful, very useful, I would say.

Sure, I will ask him on your behalf, and maybe he will listen, because you are an authority on chess matters. BTW, the FishTest forum (FishCooking) is a more direct way than TalkChess for suggestions to SF programmers. It is watched constantly by everyone who matters in SF testing. If you don't object (no adverse experience?) you can post there, and your excellent knowledge and experience will be implemented faster and fuller. But it is up to you to decide ...

Ok, going to github now.

Thanks.

Too many programmers there, a bit scary...

[lantonov]

Asked Stefan to try with / 16. There is one more test in the queue (together with apex patch) that has larger chance of success.

[lantonov]

Too many programmers there, a bit scary...

Most are not programmers, like myself. There are many testers and just chess fans. Some (Mindbreaker) are good chess players who know nothing about programming but propose useful ideas. There is even a sticky thread for suggestions. Very different people who make effort to go along with each other because of the common goal to improve the engine. You would be a very great asset to the forum. One minus though: no chess diagrams.

[Lyudmil Tsvetkov]

Asked Stefan to try with / 16. There is one more test in the queue (together with apex patch) that has larger chance of success.

I guess that one should be discarded, as it used old master.

[lantonov]

The last test of Stefan with lower bonus for long chains passed very fast on STC.

[lantonov]

Sorry, the long chain patch failed at LTC.

[Lyudmil Tsvetkov]

Just a matter of implementation, but also related to the engine's search.

1/4 fails at STC in SF, 1/8 is about neutral at STC, 1/16 does greatly at STC but scores negative at LTC, 1/11 succeeds moch much harder than 1/16 at STC but scores positive at LTC?

Really difficult to imagine what is going on.

Is it that even smaller values are better?
Or maybe smaller values will perform better at STC but worse at LTC, with bigger values performing better, even though failing at STC?

TC-dependant?
Search-dependant?

No one knows, but what is certain is that the basic concept is founded on sound chess knowledge, very sound I would say, so maybe a brilliant implementation idea might just help.

If not now, maybe in 2 year's time...

Stefan deserves all the credit for pushing the pacthes of course.

[lantonov]

There is the following about this patch on Stefan's github:
=================================================
Rocky
LOL, you are about to break the record for most dimensions for an array !
Connected[2][2][2][2][RANK_NB];

But I'm not sure about this long chain bonus...
If WHITE have a long chain, normally, BLACK will have one too...
and the bonus cancels out.
---------------------------------------------------------------------------------------
Stefan Geschwentner
@Rocky
if we give an equal bonus for each pawn then mostly yes. But here we use a fraction of connected bonus which increase with rank, so the more advanced chain gets a bigger bonus. And with the last factor of 1/16 only the 5th and 6th rank get actual a significant bonus.

[Lyudmil Tsvetkov]

There is the following about this patch on Stefan's github:
=================================================
Rocky
LOL, you are about to break the record for most dimensions for an array !
Connected[2][2][2][2][RANK_NB];

But I'm not sure about this long chain bonus...
If WHITE have a long chain, normally, BLACK will have one too...
and the bonus cancels out.
---------------------------------------------------------------------------------------
Stefan Geschwentner
@Rocky
if we give an equal bonus for each pawn then mostly yes. But here we use a fraction of connected bonus which increase with rank, so the more advanced chain gets a bigger bonus. And with the last factor of 1/16 only the 5th and 6th rank get actual a significant bonus.

Do not have the time to post specific diagrams now, but I have looked at it closely, and 2 own and enemy longer chains almost never cancel out in practice, unless they are large blocked pawn chains, which happen relatively rare.

So I would say, long own and enemy chains would cancel in about 20% of all cases at most.
Usually, one side has a longer chain, while the other does not, or one side has 2 longer chains, while the other just one, etc. They differ also in terms of ranks in the majority of cases, even if each side has exactly one long chain.

If you would be interested in a breakdown, I have looked a bit at the numbers, in standard human games 3-pawns chains constitute about 70-80% of all cases, followed by 4-pawns chains, seen in about 20% of cases, 5 and 6-pawns chains being extremely rare, taking the rest of the share.

But, this is just standard human chess from top competitions. I guess in computer chess long chains happen even much less frequently, as computers simply do not understand the concept, and that could explain why a patch could perform not well - you simply waste your calculation resources on most positions with no real added value.

So that there are different combinations of long chains: one side having chain of 3 and the other having none, or one side having chain of 4 and the other having none, or one side having chain of 5 and the other having chain of 3, etc.

So that in practice long chains almost never cancel out, except in the case of very long blocked chains, but in such case you would consider pointed chain bonus with even bigger effect.

And yes, I forgot to mention, that the usual state of chain/defended pawns on the board is a chain of 2 - one supporting and one supported pawn, which configuration happens in about 80% of cases.
So that chains of 2 are somewhere 5 times more frequent than long chains.

That might explain why the bonus for a random chain pawn is not redundant with an additional bonus for inner pawns of a longer chain, and also why you would need much more careful tests on longer chains.

Lyudmil, thanks for feeding the discussion.
When you have migrated to C++11, you might push a patch with 1/32 values.

[lantonov]

So that there are different combinations of long chains: one side having chain of 3 and the other having none, or one side having chain of 4 and the other having none, or one side having chain of 5 and the other having chain of 3, etc.

How about differentiating those combinations, e.g. giving bonus for each pawn, resuting from the difference between white and black chains? So 5 white - 3 black = bonus for 2 pawns, 4 white - 3 black = bonus for 1 pawn, etc. In cases like 3 white - 5 black = bonus for -2 pawns (i.e, malus for 2 pawns), etc. This would make the code very simple and nevertheless able to differentiate the combinations.

Sure, rank and king proximity are important, but those require additional code.