Page 3 of 5

Re: Huge simplification

Posted: Sat Apr 26, 2014 11:31 am
by Lyudmil Tsvetkov
mcostalba wrote:
Lyudmil Tsvetkov wrote: this is precisely the type of position for which the white king should receive some nice penalty, as the general pattern favours black very much, especially what concerns possible king attacks.
Why it favors black and not white? What if position is flipped? It would favor white instead?

Once detected the closed position how can SF understand if it favors white or black?

I guess in closed position the most sane thing to do is to lower scale factors (i.e moving the evaluation toward a draw), independently from the side color.
Hi Marco.

You would feel the same way if I asked you does it make sense to use null move at all. :)

Well, the position favours black, and would favour white if flipped, for the reasons I already mentioned:

1. The e4 black chain pawn, the most advanced of the chain, is pointed toward Ke1, which is on the king side, but even better would be with Kg1,h1, etc. This e4 pawn is very close to the enemy king, and it is strong, it facilitates very much black king attack.
The most advanced white chain pawn, on the other hand, c5, is far away from the black king, so it does not help with the attack, and that is a major distinction.

2. The f2 white pawn is backward, a necessary condition for the closed trick to work. In order to defend well, especially with Kg1,h1, etc., this pawn needs to advance, and it is not very easy to do so with the enemy e4 chain pawn that restricts it. You see, if you play f2-f3 and e4 was not a chain pawn, you could just change pawns and e4 disappears. Now, because it is a chain pawn close to the enemy king, it reproduces itself automatically by capturing d5e4, and that means this is already a long-term factor, and black has more time to rely on this factor to launch a king-side attack.


Very well that you submitted a test, but I think it will not help in the particular position and with the particular detector. If you want to detect draws, as the test you submitted attempts, it better for me to scale when there are at least 6 blocked pawns on all the board, and not only in the center. 6 blocked pawns already pretty much favour draw result, and it is good to scale score in that case. Even more scaling when there are 7 blocked pawns, 8 blocked pawns might mean on many occasions an automatic draw.

So that, if you would like to detect draws in fortress positions, you need another detector: i.e. when there are at least 6 blocked pawns on all the board, scale down score.

The detector I asked about, 3 blocked pawns in the center + a backward pawn for the side with the king at which the most advanced chain pawn and the chain itself is pointed, is designed to handle rich middlegame KID-type positions, which already favour one of the sides. This detector type could be meaningful in terms of elo, as a lot of wins could come from that knowledge. This is standard-type KID knowledge.

So, if anyone asks my advice what to do about the KID, I would say the following easy rule:

white pawns on c3,d4,e5, black pawns on c4,d5,e6,f7, and black king on the king side - then give 20cps penalty or so to the black king
white pawns on d3,e4,f5, black pawns on d4,e5,f6,g7, and black king on the king side - then give penalty to the black king

this completed with the mirrored positions for black
.

That is all, it should improve SF understanding of KID structures which is not optimal currently. That was basically the Joona Kiiski suggestion that passed in early January STC and scored positively in LTC. My idea is just to suggest a probably more refined approach.

So it would make sense to push a test along these lines with penalty for the kings with the above pawn structures, this should be aimed at solving the KID.

If you want to push a test that assesses draw possibilities, you need a detector with 6 blocked pawns overall. When the blocked pawns are at least 6, you can scale down the score.

Re: Huge simplification

Posted: Sat Apr 26, 2014 11:45 am
by Lyudmil Tsvetkov
Joerg Oster wrote:
mcostalba wrote:
Lyudmil Tsvetkov wrote: this is precisely the type of position for which the white king should receive some nice penalty, as the general pattern favours black very much, especially what concerns possible king attacks.
Why it favors black and not white? What if position is flipped? It would favor white instead?

Once detected the closed position how can SF understand if it favors white or black?
Black's pawn chain is pointing towards the kingside. White's chain towards the queenside. If Black castles short, there is no impact from white's chain. Contrary to black's chain, if White castles short.
So another idea might be to give a penalty for White castling short in these KID like positions. Or, if White already castled short, give a penalty to king safety.
Since this is partially redundant with pawns attacking kingRing, maybe that penalty should be increased in such positions.
Of course, that's all only valid if I correctly understood Lyudmil's idea. :lol:
Hi Joerg.

As usual, you understood my idea better than myself. :D

If you allow me, I think the best thing with such structures would be to give penalty for the king in the general case when it is on the side where the chain is pointed at, i.e. for king on e1,f1,g1,h1, regardless of whether it has castled or not.
I do not know about the penalty, maybe 20cps for a start would be OK, but who knows. What were Joona's values?

Re: Huge simplification

Posted: Sat Apr 26, 2014 12:01 pm
by Joerg Oster
Joona chose a penalty of 12cp, if I looked at the correct test.

Re: Huge simplification

Posted: Sat Apr 26, 2014 12:01 pm
by arjuntemurnikar
Lyudmil Tsvetkov wrote: But you praise me too much, I think. As Lucas says, the patch always belongs to the developer who submitted it, heart and mind.
I disagree with Lucas then. I think credit must duly go to everyone who contributed along the way, which in SF's case would be everyone who gives ideas, donates computer resources, helps in development, tests stockfish on wide range of hardware, etc. etc. You deserve a considerable portion of that credit!
Lyudmil Tsvetkov wrote: The only thing I am a bit unhappy with is when a really good idea goes down the drain because of possible implementation deficiencies. But, of course, you might be right, everything is so well tuned in SF. A thing apart is that quite possibly SF search as it is designed currently favours some eval changes while discouraging others.
Yes, it is definitely a game of "taketh and giveth", and is most surely not straightforward. But, that's the challenge!
Lyudmil Tsvetkov wrote: Your closed position idea about taking into account all blocked files, not just central ones, while giving double value for central, is indeed good for assessing drawing possibilities in the position for the weaker side, the more blocked pawns, the higher the probability for a draw. It should also help with adjusting the values of Ns and Bs, especially with a bigger number of blocked pawns. I think the approach should work, why not? But, is not it again those imbalance/quadratic tables that somehow interfere? B vs N with pawns on both sides does not work, Q imbalances in general do not work, R vs minors imbalances do not work, I think there is a reason for this and it might really be those quadratic tables that are very well tuned and prevent any further sensible imbalance code additions.
Yes, of course it should work! It is just a matter of finding the right "balance". First implementations rarely work. As for blocked positions, I didn't really consider the increase in draw probability though. I see now marco is doing something related to that. I was trying adjusting the values of the minor pieces with respect to number of blocked pawns.
Lyudmil Tsvetkov wrote: You are doing a great job lately, Arjun, congratulations! Trying to improve SF almost single-handedly is a bit difficult. I especially admired your storm effort, although I do not know its specifics, as storm danger is very important and still very far from perfection in SF. It is a pity the test failed.
Yes, pissed me off a lot that stormdanger test! I spent more than 48 hours of my cpu time tuning those values... but it is not that I spent my resources on it that I was upset about, it was that at every step of the way, every test I posted to verify the progress of the tuning gave me positive results. It was almost as if fishtest tricked me! "Hey, this is great... this is wonderful... It's working very well!"... and then when the time came to really work, "April Fool! This doesn't work!! Boo-yaa!" LOL. Sigh... I guess I cannot possibly be the only one this has ever happened to so... in a way, that cheers me up! :)
Lyudmil Tsvetkov wrote: Just briefly my vision for further improving SF storm danger code:

- add one other file towards the center that is adjacent to a file adjacent to the king itself, for example, e file with Kg8, or f file with Kh8. The values of that file however should be very low, twice as low as for the adjacent file, as the storm impact there is lower. If an f file with Kg8 gets 40cps, e file should get 20cps, not more.
- possibly add one rank, the 4th, in storm danger, with similarly low values, twice lower than for 5th rank. I have seen this is instrumental in many positions
- see if it is possible to further increase bonus for blocked storming pawn on the 6th, not only when it is edge pawn, but also for g and f files. I think this should work, as there is not a major distinction between an h6,g6 or f6 blocked storming pawn. It is just that edge pawns happen more frequently in engine games (while in my games g and f pawns are more frequent, so it is a matter of style)
Hmm...
-- The best way to tune an array like the storm danger code is to tune it using automated tools. You can't get better values than that. As I tried this already and it didn't work, I am supposing that it is already quite well tuned. Anyway, we will see...
-- I believe the 4th rank is already included. The array starts from RANK_1, RANK_2... RANK_5 (from white's pov and vice versa). So, the rank you are suggesting f5, g5, h5 square is the last value in each row. RANK_1 is mostly 0 because you can't have a pawn there, so if it has a value it indicates that we have no friendly pawn on that file at all... I know, it is a little hard to read for someone who doesn't know programming. :)
-- Adding a 4th file might be interesting, although I have doubts about it. Pawns on the d/e file don't really contribute to king safety other than maybe supporting advances of f/c pawns. Hmm... Maybe we will try it in the future. For now, I don't want to see the face of that stormdanger array! (Haha! :D)
Lyudmil Tsvetkov wrote: What concerns SF improvement in closed positions, we will see if it really improved when Marco releases next official version and I play some games against it. :D

I am very happy when patches pass the test, especially when they do so in less than 3000 games at LTC. This is a real contribution. I think your greatest achievement was removing of king exposed, I wish you many other such patches.
Wow, you really follow the game, don't you? Yes, that was a very nice simplification indeed. I must humbly admit though that at that time I wasn't really sure what I was doing. I was just playing around with the code, adding stuff here, removing stuff there, and I just so happened to by chance stumble across an elo gainer. I didn't even fully understand what it did that time... The patch I submitted that time was half-wrong (or at least it happened to do something I originally did not intend to do). Now I have a much better understanding of the eval (haha!), though there is still a lot of stockfish I don't fully understand yet. I just contribute in my spare time! :)
Lyudmil Tsvetkov wrote: It would be interesting to see how the fixed minor behind chain pawn fares.

Congratulations again, you simplified everything that was there to simplify. I am sure even the rook passers will fall. :)
Thanks.. :) Indeed some nice simplifications that I am sure marco always welcomes! The rookpassers is quite annoying. It seems to be taking forever to pass, though it is quite obvious it is elo neutral. Anyway, I can't really help it.

Re: Huge simplification

Posted: Sat Apr 26, 2014 12:57 pm
by Lyudmil Tsvetkov
Hi Arjun.

By 4th rank I meant considering in storm danger f4,g4, h4 pawns as dangerous for a black king on g8.

Re: Huge simplification

Posted: Sat Apr 26, 2014 3:28 pm
by bob
mcostalba wrote:
Lyudmil Tsvetkov wrote: the correct definition would be that a position is closed when on at least 3 of the central c,d,e or f files there are blocked pawns. I.e., a structure like white pawns on c3,d4,e5, black pawns on c4,d5,e6. The at least 3 central blocked pawns rule is the minimal requirement for a closed position, but piece values are even better adjusted with more blocked pawns.
I can write a closed position detector to be used by people to write tests on it, but I need a correct definition. From what you write pawns blocked is not enough, it seems they have to be part of a chain, is it correct?

I mean that a structure like white pawns on c2, d6, e3 and black pawns on c3,d7,e4 respect the "blocked" constrain, but I don't think is a closed position.
A position is not really blocked unless there are zero entry squares for pieces. You can have a position with all 8 pawns in a long chain, blocked, with white pieces behind white pawns and vice-versa, and it is blocked. Or you can have a blocked position with white pawns on b4, d3, e4 and g4 (with black pawns blocking those) and with just kings there are no entry squares. And there are other more complex variations of the same theme.

Re: Huge simplification

Posted: Sat Apr 26, 2014 3:29 pm
by bob
mcostalba wrote:
mcostalba wrote: I can write a closed position detector to be used by people to write tests on it
Ok I have pushed a branch called closed_positions:

https://github.com/mcostalba/Stockfish/ ... d_position

with the code that implements your definition. Now I am able to detect positions like this one:

[d]r1q2rk1/2p3pp/2Pp4/p2P1p2/Q3p3/4P3/PP1R2PP/1K5R b - - 0 23
That is not close to blocked.

Re: Huge simplification

Posted: Sat Apr 26, 2014 4:04 pm
by AdminX
bob wrote:
mcostalba wrote:
mcostalba wrote: I can write a closed position detector to be used by people to write tests on it
Ok I have pushed a branch called closed_positions:

https://github.com/mcostalba/Stockfish/ ... d_position

with the code that implements your definition. Now I am able to detect positions like this one:

[d]r1q2rk1/2p3pp/2Pp4/p2P1p2/Q3p3/4P3/PP1R2PP/1K5R b - - 0 23
That is not close to blocked.
That's semi-open! :D

Re: Huge simplification

Posted: Sat Apr 26, 2014 5:24 pm
by mcostalba
I have generalized the close position detector to evaluate any chain of blocked pawns: now is very general and flexible, the chain is evaluated according to its size and if is in the center or not. I have submitted some tests although very probably weights are wrong so I don't expect nice surprises.

Re: Huge simplification

Posted: Sat Apr 26, 2014 7:39 pm
by arjuntemurnikar
Lyudmil Tsvetkov wrote:Hi Arjun.

By 4th rank I meant considering in storm danger f4,g4, h4 pawns as dangerous for a black king on g8.
Yes same thing. 5 ranks are included: Assuming King was RANK_1, then 1, 2, 3, 4, and 5 are included.