Plunder raids and pruning bad captures

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

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

Plunder raids and pruning bad captures

Post by hgm »

If people prune bad captures in QS, do they make exceptions for captures with piece that were under attack already?

E.g. when I attack my opponent's Queen, and he would respond with a counter attack on my Queen, the 'obvious refutation' is usually that I make a 'suicide capture' with my Queen. Because when he now recaptures, I take his Queen, making it merely a trade.

So a counter-attack is usually a fatal mistake, but if in QS the suicide capture with the threatened Queen is not searched because it has negative SEE, the program would not see it.

I am especially interested in this, because counter-attacks are often a prelude to a plunder raid, where the attacks are followed by actual captures. Plunder raids can only sustain themselves if each capture of the lagging side targets a new victim at least as valuable as what the opponent threatened with his last capture. (But with pieces as strong as Queen, or even stronger, that is usually possible in multiple ways.) So you are typically in a situation where both sides have a valuable piece under attack, And making the captures is usually not the most effective defense for the leading side. A suicide capture with the threatened piece is much more likely to refute the counter attack, and put an immediate end to the plunder raid.
Daniel Shawul
Posts: 4185
Joined: Tue Mar 14, 2006 11:34 am
Location: Ethiopia

Re: Plunder raids and pruning bad captures

Post by Daniel Shawul »

hgm wrote:If people prune bad captures in QS, do they make exceptions for captures with piece that were under attack already?

E.g. when I attack my opponent's Queen, and he would respond with a counter attack on my Queen, the 'obvious refutation' is usually that I make a 'suicide capture' with my Queen. Because when he now recaptures, I take his Queen, making it merely a trade.

So a counter-attack is usually a fatal mistake, but if in QS the suicide capture with the threatened Queen is not searched because it has negative SEE, the program would not see it.
Do you mean a counter-attack is rarely fatal ? I think many do not search any kind of attacking moves in QS for fear of explosions. I can see this happening in standard chess even if we consider threats to Queen (MVP). Also there is the SEE problem and even MVV/LVA will not consider it. So surely this is probably something no one explored.
I am especially interested in this, because counter-attacks are often a prelude to a plunder raid, where the attacks are followed by actual captures. Plunder raids can only sustain themselves if each capture of the lagging side targets a new victim at least as valuable as what the opponent threatened with his last capture. (But with pieces as strong as Queen, or even stronger, that is usually possible in multiple ways.) So you are typically in a situation where both sides have a valuable piece under attack, And making the captures is usually not the most effective defense for the leading side. A suicide capture with the threatened piece is much more likely to refute the counter attack, and put an immediate end to the plunder raid.
The qsearch will consider capturing the opponent queen first. You can also try to identify this situation as perfectly as possible and apply the Queen capture that SEE tosses out. The search will stop early even if the move was a mistake since it would be a total blunder.
Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: Plunder raids and pruning bad captures

Post by Sven »

hgm wrote:If people prune bad captures in QS, do they make exceptions for captures with piece that were under attack already?

E.g. when I attack my opponent's Queen, and he would respond with a counter attack on my Queen, the 'obvious refutation' is usually that I make a 'suicide capture' with my Queen. Because when he now recaptures, I take his Queen, making it merely a trade.

So a counter-attack is usually a fatal mistake, but if in QS the suicide capture with the threatened Queen is not searched because it has negative SEE, the program would not see it.

I am especially interested in this, because counter-attacks are often a prelude to a plunder raid, where the attacks are followed by actual captures. Plunder raids can only sustain themselves if each capture of the lagging side targets a new victim at least as valuable as what the opponent threatened with his last capture. (But with pieces as strong as Queen, or even stronger, that is usually possible in multiple ways.) So you are typically in a situation where both sides have a valuable piece under attack, And making the captures is usually not the most effective defense for the leading side. A suicide capture with the threatened piece is much more likely to refute the counter attack, and put an immediate end to the plunder raid.
This is a typical inaccuracy "drawback" of SEE which only evaluates captures on the same target square. By combining SEE with certain information about pending attacks you might solve this problem but your QS code would become more complex and slower, and/or you might get a negative impact on the SEE-based pruning abilities in QS.

I think the overall effect of the problem you describe is not very big since a counter-attack (if it is neither a capture itself nor a check) does not occur within QS so that your situation only happens if the counter-attack is the last full-width ply, and the inaccuracy is very likely to either have no influence on the root, or to be corrected in the next iteration where the "suicide capture" performed by your attacked queen is still above the horizon.

Finally, to answer your first question directly: I don't make such exceptions in my engine, for the reasons given above.

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

Re: Plunder raids and pruning bad captures

Post by hgm »

Daniel Shawul wrote:Do you mean a counter-attack is rarely fatal ?
No, I meant what I said, that it is usually fatal. Proper response to a threat is to solve it, not create an equivalent counter attack.
I think many do not search any kind of attacking moves in QS for fear of explosions. I can see this happening in standard chess even if we consider threats to Queen (MVP).
In QS you would of course not search attacks through non-captures. But the point is that there can be captures that at the same time create new attacks. Especially Queen-class pieces are very adept at eating themselves through the opponent's lines; once it has breached the outer defense, it usually has a choice out of multiple captures, and each of these captures opens new attacks on several more targets.
The qsearch will consider capturing the opponent queen first. You can also try to identify this situation as perfectly as possible and apply the Queen capture that SEE tosses out. The search will stop early even if the move was a mistake since it would be a total blunder.
Well, perhaps it would be sufficient to exempt captures with a hanging piece from SEEing, even if they are HxL.(For LxH and equal captures I already skip SEE.), and that they should actually not be ranked according to the victim in the MVV ordering, but according to the value of the mover. E.g. if I have Qx(unprotected)R and Rx(protected)B, while the latter R was hanging (i.e. attacked and not protected), standard ordering would be to start with QxR, (which then is refuted by my hanging Rook being captured), and not consider the RxB at all (because SEE tells us it loses the exchange). But when saving your own hanging pieces gets priority over capturing equivalent hanging pieces of the opponent, and are tried unSEEn, the RxB would be tried first (and probably gain you a minor, because you play QxR when he recaptures the Rook, or withdraw your Rook when he saves his).

I also wonder whether captures of victims lower than your own highest hanging piece should not be considered bad captures, even if their SEE is good. E.g. if I have a hanging Rook, PxB is not so hot, because he will of course not recapture the P, but retaliate against my Rook, so that I in fact lose an exchange in the first two ply. So captures of anything worth less than a Rook are in general not advisable when I have a hanging Rook.

Hanging pieces will be much more common in Chu Shogi, because basically every piece suffering a contact attack from a Lion should be considered hanging, no matter how well it is protected. Because the Lion can withdraw from the square after capture, with the second leg of its move.

Perhaps capturing with check by hanging pieces should also get priority over capturing valuable victims.
Daniel Shawul
Posts: 4185
Joined: Tue Mar 14, 2006 11:34 am
Location: Ethiopia

Re: Plunder raids and pruning bad captures

Post by Daniel Shawul »

hgm wrote:
Daniel Shawul wrote:Do you mean a counter-attack is rarely fatal ?
No, I meant what I said, that it is usually fatal. Proper response to a threat is to solve it, not create an equivalent counter attack.
For example, white attacks q with his B, and black then replies (counter-attacks) Q with his b.Then in qsearch white has now two options: Bxq or Qxb. Thus Bxq can never loose and will be tried first but Qxb will be an equal exchange after bxQ. So black can make a counter attack or not outside the qsearch but he needs to make sure he will get equal exchange when he does a counter attack.I understand your argument that Qxb may be better than Bxq because in the latter case I know the opponent will capture my Q if I have a hanging pieces evaluator. The only advantage of Qxb would be white will have the upper hand if the raid continues with both queens attacking unprotected pieces. So that is the only
downside I see with black making the counter attack.
I think many do not search any kind of attacking moves in QS for fear of explosions. I can see this happening in standard chess even if we consider threats to Queen (MVP).
In QS you would of course not search attacks through non-captures. But the point is that there can be captures that at the same time create new attacks. Especially Queen-class pieces are very adept at eating themselves through the opponent's lines; once it has breached the outer defense, it usually has a choice out of multiple captures, and each of these captures opens new attacks on several more targets.
The qsearch will consider capturing the opponent queen first. You can also try to identify this situation as perfectly as possible and apply the Queen capture that SEE tosses out. The search will stop early even if the move was a mistake since it would be a total blunder.
Well, perhaps it would be sufficient to exempt captures with a hanging piece from SEEing, even if they are HxL.(For LxH and equal captures I already skip SEE.), and that they should actually not be ranked according to the victim in the MVV ordering, but according to the value of the mover. E.g. if I have Qx(unprotected)R and Rx(protected)B, while the latter R was hanging (i.e. attacked and not protected), standard ordering would be to start with QxR, (which then is refuted by my hanging Rook being captured), and not consider the RxB at all (because SEE tells us it loses the exchange). But when saving your own hanging pieces gets priority over capturing equivalent hanging pieces of the opponent, and are tried unSEEn, the RxB would be tried first (and probably gain you a minor, because you play QxR when he recaptures the Rook, or withdraw your Rook when he saves his).
I agree. It should be safe to try out such moves since it happens in rare occasions. From experience we know MVV/LVA without SEE works well. So trying out a few more captures "out of order" in the special case where we have a hanging pieces should not increase the tree size much. Infact I do not use SEE in Nebiyu since it is difficult to adapt it to general games. So in effect I try all captures (loosing or not) and use futility pruning one ply later to remove many of them from being searched further.If you have the hanging piece info in your eval you can reorder the moves as much as you want to achieve the desired result. I say use MVV and avoid the headache with the Lion piece.
I also wonder whether captures of victims lower than your own highest hanging piece should not be considered bad captures, even if their SEE is good. E.g. if I have a hanging Rook, PxB is not so hot, because he will of course not recapture the P, but retaliate against my Rook, so that I in fact lose an exchange in the first two ply. So captures of anything worth less than a Rook are in general not advisable when I have a hanging Rook.
I have tried this in the past when I had a hanging pieces evaluation code through Ed's attack sets. It is like doing futility pruning one ply earlier. That pruning tries only captures that bring up our score to equal levels or more. So you can achieve the same effect one ply earlier by not trying captures that don't gain more than our hanging pieces.
Hanging pieces will be much more common in Chu Shogi, because basically every piece suffering a contact attack from a Lion should be considered hanging, no matter how well it is protected. Because the Lion can withdraw from the square after capture, with the second leg of its move.
Two leg movers will definately require a re-think of SEE. It is not an exchange on the same square anymore if the lion will move away from the hot spot in the second leg.
Perhaps capturing with check by hanging pieces should also get priority over capturing valuable victims.
Yes but you can only try such schemes if SEE don't prune it already. So stick with MVV/LVA if it doesn't explode chu-shogi qsearch. Even if it does start from there, and then re-order or remove those captures that you will not want to try gradually.
User avatar
Rebel
Posts: 6946
Joined: Thu Aug 18, 2011 12:04 pm

Re: Plunder raids and pruning bad captures

Post by Rebel »

hgm wrote:If people prune bad captures in QS, do they make exceptions for captures with piece that were under attack already?

E.g. when I attack my opponent's Queen, and he would respond with a counter attack on my Queen, the 'obvious refutation' is usually that I make a 'suicide capture' with my Queen. Because when he now recaptures, I take his Queen, making it merely a trade.

So a counter-attack is usually a fatal mistake, but if in QS the suicide capture with the threatened Queen is not searched because it has negative SEE, the program would not see it.

I am especially interested in this, because counter-attacks are often a prelude to a plunder raid, where the attacks are followed by actual captures. Plunder raids can only sustain themselves if each capture of the lagging side targets a new victim at least as valuable as what the opponent threatened with his last capture. (But with pieces as strong as Queen, or even stronger, that is usually possible in multiple ways.) So you are typically in a situation where both sides have a valuable piece under attack, And making the captures is usually not the most effective defense for the leading side. A suicide capture with the threatened piece is much more likely to refute the counter attack, and put an immediate end to the plunder raid.
After loads of experiments a couple of decades back I found that obeying the original idea behind QS was best for me. The goal of QS: check if the eval of a good (above alpha) leaf is safe and the score is reliable. Meaning a QS as fast as possible. For Rebel that meant: winning & equal captures, queen promotions and allow checks in the first 2 plies in QS, all of this in an aggressive lazy-eval setting.

But of course I remain open to all kind of juicy QS extension idea's :wink:
diep
Posts: 1822
Joined: Thu Mar 09, 2006 11:54 pm
Location: The Netherlands

Re: Plunder raids and pruning bad captures

Post by diep »

hgm wrote:If people prune bad captures in QS, do they make exceptions for captures with piece that were under attack already?

E.g. when I attack my opponent's Queen, and he would respond with a counter attack on my Queen, the 'obvious refutation' is usually that I make a 'suicide capture' with my Queen. Because when he now recaptures, I take his Queen, making it merely a trade.

So a counter-attack is usually a fatal mistake, but if in QS the suicide capture with the threatened Queen is not searched because it has negative SEE, the program would not see it.

I am especially interested in this, because counter-attacks are often a prelude to a plunder raid, where the attacks are followed by actual captures. Plunder raids can only sustain themselves if each capture of the lagging side targets a new victim at least as valuable as what the opponent threatened with his last capture. (But with pieces as strong as Queen, or even stronger, that is usually possible in multiple ways.) So you are typically in a situation where both sides have a valuable piece under attack, And making the captures is usually not the most effective defense for the leading side. A suicide capture with the threatened piece is much more likely to refute the counter attack, and put an immediate end to the plunder raid.
Yes i do/tried/did do all this, but it is very tricky code. One day i intend to improve it. Even though diep sees clearly when heavy material is attacked and also keeps track of it, giving priority then to the capture move of the piece that's most under attack, *not* doing a capture because of this usually is not a good idea. It's a quiescencesearch. *some* failed overhead is better than to miss a capture that for some weird reason IS possible as it seems like.

Especially with all the dubiousity last few plies, where effectively after some reduction you get already on top of a new ply and there refute just with qsearch nullmove. So if you'd miss that in qsearch you're missing last 5 plies something pretty crucial...

As diep isn't outsearching anyone else (understatement) right now, i just can't afford missing something those last 5 plies simply.

The problem with Diep is the 'avoid moves' rather than picking up tactics.
diep
Posts: 1822
Joined: Thu Mar 09, 2006 11:54 pm
Location: The Netherlands

Re: Plunder raids and pruning bad captures

Post by diep »

Rebel wrote:
hgm wrote:If people prune bad captures in QS, do they make exceptions for captures with piece that were under attack already?

E.g. when I attack my opponent's Queen, and he would respond with a counter attack on my Queen, the 'obvious refutation' is usually that I make a 'suicide capture' with my Queen. Because when he now recaptures, I take his Queen, making it merely a trade.

So a counter-attack is usually a fatal mistake, but if in QS the suicide capture with the threatened Queen is not searched because it has negative SEE, the program would not see it.

I am especially interested in this, because counter-attacks are often a prelude to a plunder raid, where the attacks are followed by actual captures. Plunder raids can only sustain themselves if each capture of the lagging side targets a new victim at least as valuable as what the opponent threatened with his last capture. (But with pieces as strong as Queen, or even stronger, that is usually possible in multiple ways.) So you are typically in a situation where both sides have a valuable piece under attack, And making the captures is usually not the most effective defense for the leading side. A suicide capture with the threatened piece is much more likely to refute the counter attack, and put an immediate end to the plunder raid.
After loads of experiments a couple of decades back I found that obeying the original idea behind QS was best for me. The goal of QS: check if the eval of a good (above alpha) leaf is safe and the score is reliable. Meaning a QS as fast as possible. For Rebel that meant: winning & equal captures, queen promotions and allow checks in the first 2 plies in QS, all of this in an aggressive lazy-eval setting.

But of course I remain open to all kind of juicy QS extension idea's :wink:
With first 2 plies of qsearch you're not counting escaping from check as an additional ply i assume? That's what i did do in 90s. 21th century i changed it. Every qsearch position is the same and the same rules apply which moves get tried.

In diep i do checks at all levels of the qsearch *everywhere*. So giving check i mean. Most when posting here 'check' just mean escape from check...

Overhead of that is not so big, but it's a lot of code, clockcycles, so you want picking which checks to try. Even with the slow speed of Diep i really feel the code selecting which moves to try in qsearch, but it's worth it i feel.