Very nice work here !!👍👊

Very cool!. . . it will be fun to try to get it back down to symmetric 4x8 without losing elo. :)

Just a question... why isn't this being committed? I thought it passed both STC and LTC? Or am I missing something here?

      Just a question... why isn't this being committed? I thought it passed both STC and LTC? Or am I missing something here?

Maintainers do not like adding much new code or many new parameters.

Most likely they just do not always have the time to merge patches within three days or are just waiting to allow people to comment on a patch before merging it. Please be patient, I am pretty sure no maintainer is intentionally ignoring this PR.

now when http://tests.stockfishchess.org/tests/view/5c05020e0ebc5902bcee390c this patches passing SPRT I think the most logical thing to do will be next steps:

1. test 4x8 vs 8x8 LTC as [-3;1]
2. if it passes - merge 4x8
3. if it doesn't merge 8x8

OK, I'll wait with my tuning values
http://tests.stockfishchess.org/tests/view/5c03968d0ebc5902bcee15ac
until one of this get comitted.

I scheduled http://tests.stockfishchess.org/tests/view/5c0880200ebc5902bcee7d76 to gather more information.

The result was:
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 31058 W: 5024 L: 5227 D: 20807
In favor of this asymmetric psqt.

Maybe I misunderstand, but there is IMO no strong reason that pawn square tables should be symmetrical (also for other pieces I suppose but maye it is stronger for pawns) because pawns can not move freely from file to file, it mainly is a bonus to move forward more for one pawn then another and pawn storms are more likely against short castled kings. (I don't know if you can see that in the bonuses I have not checked that, the bonuses can either encourage or discourage pawnstorms on one side of the board),

IMO, these tables should be symmetric. However, since this proves to gain elo, it can be committed.

If pawns truly could be symmetric, then certainly someone can simplify it back to 4x8 without losing the elo gain. If not, then the pawns table is better left asymmetric.

In theory since all pieces apart from pawns can move forward and backward PSQTs should be 4x4.
4x8 or 8x8 are workaround about our imperfect eval heuristics, imho.

IMO, these tables should be symmetric. However, since this proves to gain elo, it can be committed.
Kingside is not equivalent to queenside.

Assuming this is the case isn't a huge issue, but it's nonetheless suboptimal. Chess is not symmetric between kingside and queenside.

Of course, depending on if the kings end up castling kingside and/or queenside, the dynamics will be different and even having the full 8x8 table is suboptimal as it mostly covers the most common situation. But the way to handle these different dynamics better is certainly not to entirely ignore them.

PSQT as a whole are a bandaid to patch limitations of eval heuristics.

when is this getting merged? its been already more than a week

@xoto10
Moving pawns away from king weakens king safety, but it also may interact with passed pawn bonuses(which are quite significant for any pawn after 2 moves).

@mcostalba I think this one should be merged. At least people will have codebase to simplify it and it's a pretty clean elo gainer :)

@Vizvezdenec patch looks good for me.

If it is merged, I hope people don't try and simplify it away immediately. There should be a chance for it to bed in, a chance to tune other parameters now that this is present, and make other adjustments to take advantage of this new feature, not just get rid of it asap.

@xoto10 I agree since the simplification attempt was already tested and failed. See my test above.

What's happening here?
Can we merge it, so we start to make some tests over this ?

OK, I have merged the patch by popular request in 883367d, congrats :-)

But I would say that I didn't like the new values at all, especially the asymmetrical endgame values:
• on the sixth rank a pawn in d6 is worth 12, and in e6 it is worth 21, that's already strange...
• but on the seventh in d7 it is worth 27, but in e7 it is worth 15, really???

@snicolet well, look at rook endgame PSQT mess now... It also makes 0 sence. Some black magics, what I can say :)

More chaos is not the way to go I think... We should take some effort and try to make these values more sensible.

The point of SPSA tuning is that automating value tuning is much more efficient than trying to hand-tweak it.

Trying to change PSQTs by hand to make it satisfy our feels is a terrible idea. We are missing the patterns that make the tuned values more sensible.

OK, I have merged the patch by popular request in 883367d, congrats :-)

But I would say that I didn't like the new values at all, especially the asymmetrical endgame values:
• on the sixth rank a pawn in d6 is worth 12, and in e6 it is worth 21, that's already strange...
• but on the seventh in d7 it is worth 27, but in e7 it is worth 15, really???

Likely because the e7 pawn will typically be more vulnerable to the black king than the d7 pawn, and at the very least would require one more tempo for a kingside castled black king to attack it. So trying to get a d file passed pawn will usually be more advantageous than trying to get an e file passed pawn.

Of course, these values are more adapted to the typical kingside castling game and are probably not that great against queenside castling ; but on average they perform better.

PSQT are very useful, because they offer a usually decent approximation with very little computational overhead. But they lack generalization and there will always be positions where they simply fail.

If some tuned PSQT values seem weird to us, this is an indication that they are trying to compensate for something that the rest of the evaluation function is missing.

This apparent weirdness for d6/e6 and d7/e7 should not be seen as a failure of the PSQT, but as a failure of the code trying to evaluate passed pawns.

It should drive attempts to improved passed pawns evaluation, not to simplify away the assymetrical PSQT.

Also, we should keep in mind that a good patch improving how e.g. passed pawns are evaluated would risk to not work as well as expected because the PSQT and the evaluation change would add up and overshoot.

Hence, logically sound patches addressing an issue pointed out by a PSQT weirdness should use a small SPSA tuning session before being tested at STC/LTC. This is a general issue at this point of StockFish's development : a genuine improvement may not be able to pass without some retuning because another piece of code is somewhat compensating the weakness and would conflict with the better way of addressing it.