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.
SEE logic
Moderators: hgm, Rebel, chrisw
-
- Posts: 719
- Joined: Thu Mar 09, 2006 1:21 am
- Location: Portland Oregon
Re: SEE logic
I don't see the point. SEE need not be eval.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: SEE logic
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.
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.
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: SEE logic
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.Evert wrote: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.
Miguel
-
- Posts: 4833
- Joined: Sun Aug 10, 2008 3:15 pm
- Location: Philippines
Re: SEE logic
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.ymatioun wrote: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.
-
- Posts: 1564
- Joined: Thu Jul 16, 2009 10:47 am
- Location: Almere, The Netherlands
Re: SEE logic
In the latest version of my engine I also use the values from the PST.ymatioun wrote: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.
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.
-
- Posts: 2
- Joined: Sun Mar 02, 2014 11:05 am
Re: SEE logic
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.
Unless your SEE implementation handles xrays, pinned pieces, capture orderings and zwischenzugs, you're worrying about a small inaccuracy and ignoring much larger ones.
-
- Posts: 3232
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: SEE logic
+1hwiechers wrote: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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: SEE logic
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.michiguel wrote: 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.
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.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: SEE logic
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.