SEE and en passant

[Pablo Vazquez]

Let me add one bit of clarification to my comments. MVV/LVA without any SEE at all is definitely worse than just using SEE. The MVV/LVA benefit shows up when applied to moves that have been pre-screened so that you do not look at losing captures early in the search. Just pure MVV/LVA is on the order of 10% worse than pure SEE, in terms of tree size. If you can get your SEE fast enough, you win. Else you lose or break-even. But if you screen the moves and then search in MVV/LVA order, it is a definite win.

Engines are different, and as Bob often says your mileage may vary.
In Tinker, MVV/LVA without SEE in the full width search is better.

Bob, please clarify this

The MVV/LVA benefit shows up when applied to moves that have been pre-screened so that you do not look at losing captures early in the search.

What is meant by "pre-screened"?
MVV/LVA does not show if a capture is losing or not.
So, is pre-screening just V >= A or also using SEE?

This is from the discussion here last year (CCC). I do the following to choose captures to search at the beginning of any ply.

1. If this is a small x big capture, it is always included. PxN, RxQ, etc. In addition, if it is an exchange (minor x minor, PxP, etc) it is also included automatically.

2. If this is a big x small capture, it is riskier and has to pass the SEE test to be sure it doesn't lose material (QxN where N is undefended is good, QxR where rook is defended might be bad, etc).

For any moves that pass either of the above, they are collected and then ordered by MVV/LVA, so that the most valuable piece that doesn't lose material is captured first, even though it might not appear to be the biggest material gain. For example we would try QxQ (expected gain = 0 as queen is defended) before we try NxP where P is undefended...

Hope that is clear. I tried several variations last year when this MVV/LVA discussion came up and I found this was actually a small Elo improvement over pure SEE. Not a big one, but 4-5 as I recall... You can probably find the discussion. It was within the past 12 months...

Another way of doing it is sorting them by mvv/lva and while you are trying them, if the captured piece is less valuable than the capturing piece, try SEE, and if it is a losing capture, push it to the bad captures list and go to the next capture.

That way, you save some SEE calls in case you get a cutoff.

Not a bad idea at all, I'll certainly give it a try.

Talking about bad captures, I wonder if you have done some testing on where to try them: after good and even captures, after killers, or after all other moves have been searched?

[bob]

Let me add one bit of clarification to my comments. MVV/LVA without any SEE at all is definitely worse than just using SEE. The MVV/LVA benefit shows up when applied to moves that have been pre-screened so that you do not look at losing captures early in the search. Just pure MVV/LVA is on the order of 10% worse than pure SEE, in terms of tree size. If you can get your SEE fast enough, you win. Else you lose or break-even. But if you screen the moves and then search in MVV/LVA order, it is a definite win.

Engines are different, and as Bob often says your mileage may vary.
In Tinker, MVV/LVA without SEE in the full width search is better.

Bob, please clarify this

The MVV/LVA benefit shows up when applied to moves that have been pre-screened so that you do not look at losing captures early in the search.

What is meant by "pre-screened"?
MVV/LVA does not show if a capture is losing or not.
So, is pre-screening just V >= A or also using SEE?

This is from the discussion here last year (CCC). I do the following to choose captures to search at the beginning of any ply.

1. If this is a small x big capture, it is always included. PxN, RxQ, etc. In addition, if it is an exchange (minor x minor, PxP, etc) it is also included automatically.

2. If this is a big x small capture, it is riskier and has to pass the SEE test to be sure it doesn't lose material (QxN where N is undefended is good, QxR where rook is defended might be bad, etc).

For any moves that pass either of the above, they are collected and then ordered by MVV/LVA, so that the most valuable piece that doesn't lose material is captured first, even though it might not appear to be the biggest material gain. For example we would try QxQ (expected gain = 0 as queen is defended) before we try NxP where P is undefended...

Hope that is clear. I tried several variations last year when this MVV/LVA discussion came up and I found this was actually a small Elo improvement over pure SEE. Not a big one, but 4-5 as I recall... You can probably find the discussion. It was within the past 12 months...

Another way of doing it is sorting them by mvv/lva and while you are trying them, if the captured piece is less valuable than the capturing piece, try SEE, and if it is a losing capture, push it to the bad captures list and go to the next capture.

That way, you save some SEE calls in case you get a cutoff.

Not a bad idea at all, I'll certainly give it a try.

Talking about bad captures, I wonder if you have done some testing on where to try them: after good and even captures, after killers, or after all other moves have been searched?

I try them fairly early because they are at the front of the move list anyway.

My order is as follows:

1. hash move
2. non-losing captures (accordng to SEE) ordered by MVV/LVA
3. killer moves
4. rest of captures followed by non-captures

I've tried moving them to the end of the list but it made no difference. It does seem to hurt tactical positions to do that since many are based on sacrificial themes and trying the losing captures early leads to the solution more quickly.

[mcostalba]

Another way of doing it is sorting them by mvv/lva and while you are trying them, if the captured piece is less valuable than the capturing piece, try SEE, and if it is a losing capture, push it to the bad captures list and go to the next capture.

That way, you save some SEE calls in case you get a cutoff.

This is a nice idea. I have measured a small but real speed increase applying a patch that does what you suggested. You save some SEE calls but have a little bit more sorting to do because captures are now a bit more but at the end net result seems positive.

Probably this patch will end up in the new Stockfish release with proper credit to you added as a comment to the code.

Thanks
Marco

[Zach Wegner]

This is a nice idea. I have measured a small but real speed increase applying a patch that does what you suggested. You save some SEE calls but have a little bit more sorting to do because captures are now a bit more but at the end net result seems positive.

Probably this patch will end up in the new Stockfish release with proper credit to you added as a comment to the code.

Thanks
Marco

Both Fruit and Rybka/Strelka have used this idea for years.

[mcostalba]

This is a nice idea. I have measured a small but real speed increase applying a patch that does what you suggested. You save some SEE calls but have a little bit more sorting to do because captures are now a bit more but at the end net result seems positive.

Probably this patch will end up in the new Stockfish release with proper credit to you added as a comment to the code.

Thanks
Marco

Both Fruit and Rybka/Strelka have used this idea for years.

In this case I missed it, I mean from Fruit/Toga, because I never accessed Rybka/strelka sources.

[hgm]

This is also how Joker does it. It extracts the MVV/LVA move, but if it is HxL (or the victim is of lower value than a threatened piece of ours) it subjects it to a SEE, and then replaces the MVV as sort key by the SEE value, and goes on extracting another move.

[hgm]

This is also how Joker does it. It extracts the MVV/LVA move, but if it is HxL (or the victim is of lower value than a threatened piece of ours) it subjects it to a SEE, and then replaces the MVV as sort key by the SEE value, and goes on extracting another move.

[Pablo Vazquez]

Another way of doing it is sorting them by mvv/lva and while you are trying them, if the captured piece is less valuable than the capturing piece, try SEE, and if it is a losing capture, push it to the bad captures list and go to the next capture.

That way, you save some SEE calls in case you get a cutoff.

This is a nice idea. I have measured a small but real speed increase applying a patch that does what you suggested. You save some SEE calls but have a little bit more sorting to do because captures are now a bit more but at the end net result seems positive.

Probably this patch will end up in the new Stockfish release with proper credit to you added as a comment to the code.

Thanks
Marco

The idea is actually from strelka, so I guess Yuri or Vasik deserve the credit.