SEE logic

[ymatioun]

From all the posts here i got the impression that everybody uses just captured piece values in SEE.

But i set-up my SEE to also include piece-square values of all the moves made. It is definitely slower, but i think it adds a lot of value. But i never tested impact of this on engine playing strength.

Does anybody else include PST values in SEE score? Have anybody tried this approach? Any thoughts?

Thanks.

[Ryan Benitez]

I don't see the point. SEE need not be eval.

[Evert]

Why would you include piece square tables in the return value of SEE?

The purpose of SEE is to distinguish losing captures from winning captures for pruning and possibly move ordering. For move ordering it makes sense to keep track of piece square values, but especially for non-captures. For anything else, not so much.

[michiguel]

Why would you include piece square tables in the return value of SEE?

The purpose of SEE is to distinguish losing captures from winning captures for pruning and possibly move ordering. For move ordering it makes sense to keep track of piece square values, but especially for non-captures. For anything else, not so much.

It will make it more accurate, after all a piece is worth depending where is located, but the question is if it is worth it (I would bet most likely no). A technical problem is how to deal with PST from "opening" or "ending". I think all this depends of the engine and what it does, but the thought is interesting.

Miguel

[Ferdy]

From all the posts here i got the impression that everybody uses just captured piece values in SEE.

But i set-up my SEE to also include piece-square values of all the moves made. It is definitely slower, but i think it adds a lot of value. But i never tested impact of this on engine playing strength.

Does anybody else include PST values in SEE score? Have anybody tried this approach? Any thoughts?

Thanks.

I have not tried it and I think it is an interesting idea. Good to try is capture SEE only + PST. For move ordering, it is nice to search first the move in the four central squares than in the edge of the board, provided the SEE in both area is the same.

[Joost Buijs]

From all the posts here i got the impression that everybody uses just captured piece values in SEE.

But i set-up my SEE to also include piece-square values of all the moves made. It is definitely slower, but i think it adds a lot of value. But i never tested impact of this on engine playing strength.

Does anybody else include PST values in SEE score? Have anybody tried this approach? Any thoughts?

Thanks.

In the latest version of my engine I also use the values from the PST.
It is a little bit slower, but not by much. In some positions it behaves clearly better in others it is worse. On average it does not make a big difference, but I just leave it in because I have the feeling it is theoretically better.

In my engine the move order for captures is determined by the SEE values, when you have another way of determining move order for captures it probably doesn't make sense to use the PST.

[hwiechers]

Including the PST values doesn't make sense to me.

Unless your SEE implementation handles xrays, pinned pieces, capture orderings and zwischenzugs, you're worrying about a small inaccuracy and ignoring much larger ones.

[lucasart]

Including the PST values doesn't make sense to me.

Unless your SEE implementation handles xrays, pinned pieces, capture orderings and zwischenzugs, you're worrying about a small inaccuracy and ignoring much larger ones.

+1

[Evert]

It will make it more accurate, after all a piece is worth depending where is located, but the question is if it is worth it (I would bet most likely no). A technical problem is how to deal with PST from "opening" or "ending". I think all this depends of the engine and what it does, but the thought is interesting.

This makes sense to me for move ordering, where I do agree that including the PST value, even if only as a tie-breaker between otherwise equally good captures, is a good idea. I just wouldn't put that in SEE itself.
For determining if a capture is winning or losing it doesn't make so much sense to me, but it's not going to make a difference except for equal captures (SEE=0) either.

[hgm]

Some of my engines use PST values too to qualify captures as good, bad or dubious. (I usually don't do a full SEE.) It doesn't cost anything extra to fetch the value as PST[sqr] compared to value[piece]. Especially in Xiangqi, where the value of a piece is wildly dependent on where it is located, this makes a lot of sense.