What should the next step be ?

[flok]

Nice!
Do you have more of those test-positions?

Embla did these fine

[Patrice Duhamel]

It is a problem, of course - but the solution is obvious

Sorry, I don't understand.

It's wrong to use non symetrical PST ?
Example for white, I give a penality for the King on D1 and F1, and a bonus on G1 and C1.

[MahmoudUthman]

Very low hanging fruit that you still have left would be to implement futility pruning and LMR. Both of which can be implemented with only a couple of lines of code.

How much elo gain should I expect ?

If you have not already done so, the next step should be to test very thoroughly to ensure that everything is implemented correctly and bug free.

For instance, if your centipawn evaluation does not agree exactly for these four positions:
r3rk2/ppp1q1pp/2n5/5bN1/2B1pP2/Q7/PPP4P/1KR3R1 w - - bm Nxh7+;
2kr3r/pp1q1ppp/5n2/1Nb5/2Pp1B2/7Q/P4PPP/1R3RK1 w - - bm Nxa7+;
1r3rk1/p4ppp/7q/2pP1b2/1nB5/5N2/PP1Q1PPP/2KR3R b - - bm Nxa2+;
1kr3r1/ppp4p/q7/2b1Pp2/5Bn1/2N5/PPP1Q1PP/R3RK2 b - - bm Nxh2+;

then something is broken.

I've been testing it for a while know and I'm almost certain it's bug free , the eval of the positions you gave is exactly the same , but there one thing my king safety reports an extremely high score compared to stock fish's ~3 mine reports ~>6 , does this mean that it's so high or is this position really dangerous for black ?

[cdani]

Very low hanging fruit that you still have left would be to implement futility pruning and LMR. Both of which can be implemented with only a couple of lines of code.

How much elo gain should I expect ?

At least a hundred, just to say an order of magnitude.

If you have not already done so, the next step should be to test very thoroughly to ensure that everything is implemented correctly and bug free.

For instance, if your centipawn evaluation does not agree exactly for these four positions:
r3rk2/ppp1q1pp/2n5/5bN1/2B1pP2/Q7/PPP4P/1KR3R1 w - - bm Nxh7+;
2kr3r/pp1q1ppp/5n2/1Nb5/2Pp1B2/7Q/P4PPP/1R3RK1 w - - bm Nxa7+;
1r3rk1/p4ppp/7q/2pP1b2/1nB5/5N2/PP1Q1PPP/2KR3R b - - bm Nxa2+;
1kr3r1/ppp4p/q7/2b1Pp2/5Bn1/2N5/PPP1Q1PP/R3RK2 b - - bm Nxh2+;

then something is broken.

I've been testing it for a while know and I'm almost certain it's bug free , the eval of the positions you gave is exactly the same , but there one thing my king safety reports an extremely high score compared to stock fish's ~3 mine reports ~>6 , does this mean that it's so high or is this position really dangerous for black ?

You will find positions like this all the time. I try to analyze it and see if my engine is giving a reasonable evaluation. If not, I try to figure what to change, and then I test it, of course.

[Vinvin]

It is a problem, of course - but the solution is obvious

Sorry, I don't understand.

It's wrong to use non symetrical PST ?
Example for white, I give a penality for the King on D1 and F1, and a bonus on G1 and C1.

When there's no more castling right, everything should be symmetric.

[Patrice Duhamel]

When there's no more castling right, everything should be symmetric.

I tried to do something that do not depend on castling rights, I will fix this.

[Sven]

When there's no more castling right, everything should be symmetric.

I tried to do something that do not depend on castling rights, I will fix this.

I would not call it "wrong" to have an asymmetric PST. I just think it makes life easier to have less "exceptional" stuff. My PST is symmetrical so a king on F1 gets the same penalty as on C1. I think one advantage of having a symmetrical (king) PST is to avoid some redundancy, for instance a king on D1/E1 could be safer than on G1 due to protecting pawns which is a different term (pawn shields) than the king location itself which is covered by the PST. It could as well be ok to have an asymmetrical PST, in this case you would simply remove a part of the symmetry tests that were suggested above.

[Patrice Duhamel]

I would not call it "wrong" to have an asymmetric PST. I just think it makes life easier to have less "exceptional" stuff. My PST is symmetrical so a king on F1 gets the same penalty as on C1. I think one advantage of having a symmetrical (king) PST is to avoid some redundancy, for instance a king on D1/E1 could be safer than on G1 due to protecting pawns which is a different term (pawn shields) than the king location itself which is covered by the PST. It could as well be ok to have an asymmetrical PST, in this case you would simply remove a part of the symmetry tests that were suggested above.

Thanks, I will try to use symmetrical PST, it looks more simple.

[PK]

Penalty for a king on D1 or F1 makes sense, only try to implement it outside piece/square tables. In my program king on E1 gets small bonus *if* it has castling rights. On D1 this bonus is out of the question. F1 is more complicated - it is not inherently worse than C1, except that king on F1 tends to block own rook. So I apply another penalty if the king is on F1 or G1 and a rook on G1 or H1 or H2.

Having said that, there is a strong program Hakkapeliitta and it uses decidedly asymmetric piece/square tables.

[petero2]

Having said that, there is a strong program Hakkapeliitta and it uses decidedly asymmetric piece/square tables.

I have asymmetric PSTs in texel too. For a long time I did not implement them because it is "theoretically wrong" to have left/right asymmetry when no castling rights remain. However I finally I gave in and made the tables asymmetric to get a +11 elo improvement.

I think it should be possible to come up with some other evaluation terms that give the same elo advantage without giving up the left/right symmetry, but I have not found them yet. (To be fair I have not looked that hard either.)

In chess programming a trade-off often has to be made between "correct code" and fast code. Code that is always fast but occasionally "incorrect" is sometimes better than code that is a bit slower but "theoretically correct".

If your only goal is to maximize elo the average performance is what matters, so you can get away with reasoning something like this: "Yes, I know this patch causes a crash once every 2^64 nodes, but the speedup is X percent, so the net effect on elo is positive."