SEE

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
abulmo
Posts: 151
Joined: Thu Nov 12, 2009 5:31 pm
Contact:

SEE

Post by abulmo » Thu Feb 13, 2014 10:31 pm

[D]6k1/5ppp/3r4/8/3R2b1/8/5PPP/R3qB1K b - - 0 1[/D]

In the above position, the value of the Static Exchange Evaluation (SEE) of the bishop move g4d1 depends on the order of the two white rook moves. With the following sequence of moves Bd1 Raxd1 Qxd1 Rxd1 Rxd1, it looks like the square d1 is dangerous for the bishop, but with this sequence: Bd1 Rdxd1 Rxd1 Raxd1 Qxd1, the square appears safe for the bishop. Obviously, the first sequence is the right one, and d1 is dangerous ofr the bishop, however I have no idea on how to try Raxd1 first to Rdxd1.

In case of several pieces of the same value, do you try all of them, or do you chose a random sequence and tolerate the inaccuracy of the SEE?
Richard

Daniel Shawul
Posts: 3520
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: SEE

Post by Daniel Shawul » Thu Feb 13, 2014 11:57 pm

Ofcourse I do not worry about such situations in SEE, but you can solve it by first capturing with pieces that are not blocking opponent pieces that are attacking the same target square. In your example the Rook on d file was blocking the black rook so it should have lower priority than other rooks. But I am sure there will be more complicated situations to address if one wants to have a perfect SEE.

syzygy
Posts: 4343
Joined: Tue Feb 28, 2012 10:56 pm

Re: SEE

Post by syzygy » Fri Feb 14, 2014 12:22 am

Perfect SEE is called qsearch.
Of course qsearch is not perfect either...

AlvaroBegue
Posts: 898
Joined: Tue Mar 09, 2010 2:46 pm
Location: New York
Full name: Álvaro Begué (RuyDos)

Re: SEE

Post by AlvaroBegue » Fri Feb 14, 2014 12:43 am

syzygy wrote:Perfect SEE is called qsearch.
Of course qsearch is not perfect either...
It's not so much a matter of being perfect. But it's kind of unsettling that the order of the moves might make a difference. For instance, if you were to evaluate the symmetric of this position, exchanging the roles of white and black, you could actually get a different answer.

I guess you should prioritize moves that enable x-ray attacks from your own pieces (least-valuable attackers first), then non-x-ray-enabling moves, then moves that enable x-ray attacks from the opponent's pieces (most-valuable attackers first).

But I am not sure if being so careful would pay off in any way. I would like to hear about the results if anyone tests this.

User avatar
hgm
Posts: 22618
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: SEE

Post by hgm » Fri Feb 14, 2014 6:14 am

When there is 'foe backing' SEE is inherently unreliable. After Bd1 white will play Rxd6, so who cares about the Bishop?

The assumption underlying SEE is that the tactics will remain limited to a single square. When one of the participating pieces is blocking a an opponent piece, that is just not true, because they also attack each other. (Exception could be a Pawn backed by a Bishop.)

mvk
Posts: 589
Joined: Tue Jun 04, 2013 8:15 pm

Re: SEE

Post by mvk » Fri Feb 14, 2014 10:35 pm

abulmo wrote:[D]6k1/5ppp/3r4/8/3R2b1/8/5PPP/R3qB1K b - - 0 1[/D]

In the above position, the value of the Static Exchange Evaluation (SEE) of the bishop move g4d1 depends on the order of the two white rook moves. With the following sequence of moves Bd1 Raxd1 Qxd1 Rxd1 Rxd1, it looks like the square d1 is dangerous for the bishop, but with this sequence: Bd1 Rdxd1 Rxd1 Raxd1 Qxd1, the square appears safe for the bishop. Obviously, the first sequence is the right one, and d1 is dangerous ofr the bishop, however I have no idea on how to try Raxd1 first to Rdxd1.

In case of several pieces of the same value, do you try all of them, or do you chose a random sequence and tolerate the inaccuracy of the SEE?
Why prescore Bd1 over Qxa1? SEE is about getting the best move upfront the most of the time. Later moves don't matter.
[Account deleted]

phenri
Posts: 284
Joined: Tue Aug 13, 2013 7:44 am

Re: SEE

Post by phenri » Fri Feb 14, 2014 11:08 pm

abulmo wrote:[D]6k1/5ppp/3r4/8/3R2b1/8/5PPP/R3qB1K b - - 0 1[/D]

In the above position, the value of the Static Exchange Evaluation (SEE) of the bishop move g4d1 depends on the order of the two white rook moves. With the following sequence of moves Bd1 Raxd1 Qxd1 Rxd1 Rxd1, it looks like the square d1 is dangerous for the bishop, but with this sequence: Bd1 Rdxd1 Rxd1 Raxd1 Qxd1, the square appears safe for the bishop. Obviously, the first sequence is the right one, and d1 is dangerous ofr the bishop, however I have no idea on how to try Raxd1 first to Rdxd1.

In case of several pieces of the same value, do you try all of them, or do you chose a random sequence and tolerate the inaccuracy of the SEE?
Bd1 Ra8 is not mate?

xmas79
Posts: 286
Joined: Mon Jun 03, 2013 5:05 pm
Location: Italy

Re: SEE

Post by xmas79 » Fri Feb 14, 2014 11:55 pm

I tried to stuff such precision into SEE, but I think that SEE is just an approximation... If you have long captures sequences in your search tree then your SEE wil be intrinsically inaccurate because you can probably choose among two or more captures (and probably in different squares). If you have only one long sequence, qsearch will be fast enough to cover it...

In my code I left a comment like "If we have two rooks: TODO..."

abulmo
Posts: 151
Joined: Thu Nov 12, 2009 5:31 pm
Contact:

Re: SEE

Post by abulmo » Sun Feb 16, 2014 7:12 pm

I guess I am going to not worry about this kind of position either. It looks hard to make SEE fast and efficient in such positions.
Richard

abulmo
Posts: 151
Joined: Thu Nov 12, 2009 5:31 pm
Contact:

Re: SEE

Post by abulmo » Sun Feb 16, 2014 7:19 pm

I know SEE is not perfect, but a more efficient SEE can help in better move ordering or to cut off more precisely bad moves in qsearch (or other situations). However SEE must be both fast to compute (otherwise use qsearch instead) and accurate enough (or just stick to MVVLVA if SEE does not do better). My SEE implementation seems to work fine except in situation like the one I describe.
Richard

Post Reply