Hotspots

[jdart]

I have always been somewhat reluctant to tune piece values, because I have a lot of other material scoring terms (for particular kinds of imbalances, for example) that would interact with them. These would all have to be tuned together.

FYI SPSA is known to have slow convergence near the end of a tuning cycle. I have an implementation of an improved version (RSPSA) here: https://github.com/jdart1/arasan-chess/ ... /rspsa.cpp that does better in that respect.

But I have also been using this software: http://www.adrl.ethz.ch/doku.php/adrl:software (designed for a robotics application), which in my experience converges even faster. The author is working on adding support for box constraints.

--Jon

[Lyudmil Tsvetkov]

Of course, Pawel made a great discovery that attacking enemy pieces on the long diagonal is essential for the trick to work, and we should all be grateful to him.
But besides from this, we should also try to somehow reflect the king safety aspect of the fianchettoed bishop.

Here is my vision:

- king fianchettoe will ne any bishop on g2,h1.f3

- add 5cps bonus for any enemy piece, rook, knight or maybe queen on that diagonal; add another 2cps for any enemy pawn on that diagonal, so here we somewhat develop the idea of Pawel, as attacking pawns is also important

- add another 2cps bonus for any own pawn on square adjacent to the bishop, either in front of the bishop or next to it; this will reflect the king safety aspect of the bishop, as pawns go forward, the safety bonus will be lowered

The very nice thing about this implementation is that it will automatically adjust the value of the bishop on the long diagonal in terms of available enemy objects to attack and own pawns providing king safety, so the engine can wisely decide if it makes sense to fianchettoe, or maybe it is better to develop the bishop in the center.

[d]r1bq1rk1/ppp1bppp/2n1pn2/3p4/2PP4/5NP1/PP2PPBP/RNBQ1RK1 b - - 0 1

above, you give 5cp to Bg2 for attacking black Nc6, anoter 5cps for attacking black Ra8, another 2cps for attacking pawn on b7, 2cps for pawn on d5, 2cps each for white pawns on adjacent f2,g3 and h2 squares.

Total bonus will be 20cps.
When Nc6 is not on the long diagonal, Bg2 will get 5cps less, when Ra8 gets to Rb8 another 5cps less, when the b7 pawn advances, another 2cps less, etc.; also, when white h2 pawn advances to h4, another 2cps less, when g3 pawn advances to g4, another 2cps less, etc.

So this automatically adjusts the value of the bishop, which is really very nice and might help you to tune the bonus of the bishop with other relevant psqt/mobility terms easier.

What do you think of this further refinement?
Anyone besides Pawel having tried to implement this?

Maybe someone of the SF team will also get interested, as SF badly needs this term.

[Lyudmil Tsvetkov]

Why is it important to score enemy pieces on the long diagonal?

well, a bishop on any other diagonal might attack one or 2 enemy objects at most at a time, while a bishop on the long diagonal might attack up to 5! enemy objects, on squares e4,d5,c6,b7 and a8; so this is a special case of x-ray attacking

Why is it important to score own pawns on adjacent squares?

well, very simple: a king with pawns around it is safe, a king with bishop around it is somewhat safe, and a king with pawns and a bishop around it is safest. So you clearly should reflect this special case of king safety.

[Lyudmil Tsvetkov]

I think also the king location should be restricted to h1,g1,h2, as other king squares are more or less irrelevant.

Of course, the king fianchettoe can also happen extremely rarely on the queen side, when king is on b1,a1,a2, with Bb2.

Actually, the only player I have seen to frequently use this setup on the queen side is Fischer.

[lantonov]

I think also the king location should be restricted to h1,g1,h2, as other king squares are more or less irrelevant.

Of course, the king fianchettoe can also happen extremely rarely on the queen side, when king is on b1,a1,a2, with Bb2.

Actually, the only player I have seen to frequently use this setup on the queen side is Fischer.

At the moment, SF doesn't know that fianchetto exists (no word 'fianchetto' in SF code). There were candidate fianchetto patches in the past which didn't pass, unfortunately.

Maybe a small bonus should be given to the f1/f8 bishop in the opening to sometimes go to g2/g7.

[lantonov]

Unfortunately, Joerg's patch scored just yellow.

Maybe we can push the alternative version now, until Joerg further improves on his values, I mean until Joerg's SPSA further improves...

The test started after a failed second Joerg's try. SPSA is very slow to converge. I think we need another method.

[lantonov]

These values are too initial for any change in them to be successful. All the subsequent more particular values are tuned to those so some local optimum exists. It is hard steer away from it.

[Lyudmil Tsvetkov]

These values are too initial for any change in them to be successful. All the subsequent more particular values are tuned to those so some local optimum exists. It is hard steer away from it.

That is not the problem - the problem is that this simply does not work.

Joerg's initial values included the very non-sensical bigger knight value for the eg. Utterly lacks any sense. And yet it scores well.

Now, Joerg pushes a second patch with much more sensical lower knight eg value, and it quickly fails. It absolutely makes no sense. Absolutely.

Only reasonable explanation is imbalances are interfering again, but I do not believe that either.

I watched so many games where values should go exactly the way of Joerg's second patch and the patch that is currently running and going to fail in the same way, so many games, but the most reasonable thing fails. I absolutely have no explanation.

Well, maybe everything can happen at 15 sec. games, so the engine simply gets it all quite wrong, but I do not believe that either. It simply makes no sense.

[lantonov]

These values are too initial for any change in them to be successful. All the subsequent more particular values are tuned to those so some local optimum exists. It is hard steer away from it.

That is not the problem - the problem is that this simply does not work.

Joerg's initial values included the very non-sensical bigger knight value for the eg. Utterly lacks any sense. And yet it scores well.

Now, Joerg pushes a second patch with much more sensical lower knight eg value, and it quickly fails. It absolutely makes no sense. Absolutely.

Only reasonable explanation is imbalances are interfering again, but I do not believe that either.

I watched so many games where values should go exactly the way of Joerg's second patch and the patch that is currently running and going to fail in the same way, so many games, but the most reasonable thing fails. I absolutely have no explanation.

Well, maybe everything can happen at 15 sec. games, so the engine simply gets it all quite wrong, but I do not believe that either. It simply makes no sense.

This is exactly what I tried to explain (to myself too) with the above. The values that are reasonable to you, are "unreasonable" to the program because all the other values are tuned to the values that are unreasonable to you.

[Lyudmil Tsvetkov]

It looks like it will never pass.
I do not like such patches at all. At one point it was at 2.72 LLR, just 10 more wins and would be through, but now back again at 1.42.


From the info we also have from Joerg's patch, I know what needs to be corrected, so that the patch performs better - increase somewhat queen mg and eg value, or maybe just not decrease it from original values.

If I had another attempt to push, I would go with values like:

PawnValueMg = 194, PawnValueEg = 256,
KnightValueMg = 817, KnightValueEg = 846,
BishopValueMg = 840, BishopValueEg = 865,
RookValueMg = 1278, RookValueEg = 1294,
QueenValueMg = 2518 QueenValueEg = 2555

or, even a bit more cps for the queen:

PawnValueMg = 194, PawnValueEg = 256,
KnightValueMg = 817, KnightValueEg = 846,
BishopValueMg = 840, BishopValueEg = 865,
RookValueMg = 1278, RookValueEg = 1294,
QueenValueMg = 2520 QueenValueEg = 2559

Btw., now, already too late, well beyond 6 futile attempts, I also learned what was wrong with the rook psqt: lack of synchrony between mg and eg values.

As older values were almost flat for the mg and fully flat fro the eg, this worked quite normal, although values were more or less crude; when we add rank bonus, but do this just for the mg, already inconsistency problems arise with interpolation. So, the natural thing to be done for the tables to perform better, is to just use the same tables for mg and eg with rank-based approach.

Unfortunately, it is too late now.