high values of pst

[DustyMonkey]

Who is doing automated PST tuning, and which direction are the values headed?

[D Sceviour]

While trying Texel's tuning method, I noticed a big reduction in material values due to PSQT. For example, the delta for a knight could be in the range of +/-25. Thus, the Texel tuning material value for knight averaged only 272 when using PSQT, but averaged 314 with PSQT turned off. As mentioned by others, I find continual adjustments seem to needed to reduce the values of PSQT. For kings, I use a center-gravity formula instead of PSQT. Also, PSQT is very dangerous to use in asymmetric positions. In knight versus bishop, the knight material value can be over-rated compared to the bishop due to PSQT. On the other hand, PSQT is very useful for scaling move ordering.

[lauriet]

I started with high values in my PST and found that the sum of all the positional values calculated from the PST could be greater than a pawn........resulting in loosing material for a perceived greater position. I had to reduce the values and also included an alert if the pos' value was greater than 100 (pawn value).
I use mobility now more so than using PST.

[mar]

Yes that's interesting.
I did the dumb thing and Texel-tuned PSQ tables square-by-square
Not only did it take long, it also revealed some interesting problems.

Because I tuned PSQ tables last (I tuned 1 paremeter at once instead of tuning all at once - most likely another bad idea), my theory is that the tuner tried to bake missing eval knowledge (or bad knowledge formulation) into my PSQs.
For example, queen PSQ in opening at F8..H8 (from white's POV) has values over 100cp, which is a nonsense of course.
Another possibility is that my opening=>endgame interpolation constants aren't so good and that's why some PSQs are too large - to match the interpolation.

This hints at problems with king safety evaluation. Also it hints that the test games (openings) mostly castled kingside.

Also tuning square-by-square means there may not be enough information for each square and it confuses the tuner thinking that a certain piece at some square is almost impossibly good.

Despite all those problems, Texel-tuning my whole eval worked like a wonder and I gained ~100 elo and I'm grateful for that.

[mar]

... which leads me to another thought: maybe simply testing Chess960 instead of orthodox would be the best thing to do; and if 960 positions isn't enough then a 1-move Chess960 "book" would certainly be

[jdart]

I don't mess with the tuned values, even if they don't make sense to the naked eye.

Most of mine are < 1 pawn but moving the King off the back 2 ranks in the midgame is apparently worth a penalty of >1 pawn. This in addition to whatever the king safety score computes.

--Jon

[lucasart]

Hi all
I noticed in a lot of engines sources (and at CPW too) pst values are always so high.
I tried that in Isa and didn't work very well. With high values Isa " create " an artificial advantage say +1.00 or even +1.5 ( even higher sometimes lol) and lose .
Have you some expérience/advices with this phenomenon?
Is there some reasons for that?
Isa have a lot of parameters in his eval and I think it's the main reason

I tried to decrease some values yesterday and the scores are less crazy lol
Must be tune again
We'll see..
Bests
Dany

Just use an auto-tuner, and you will see which values are correct for your engine. Optimal values for one engines are generally not optimal for another. For example, I tried to use SF's PST values, and it failed hard in testing. I also tried the reverse, to plug my PST in SF, and it failed miserably too. Of course, to ease tuning, you should start by reducing the number of variables, by having parametric PST.

Here are my PST, if you're interested:
https://github.com/lucasart/Demolito/bl ... /src/pst.c

PS: The only really important PST are King and Knight. The rest, although not useless, isn't worth much elo, so it's not very sensitive.