SEE is not working for me. Any idea why?

[mathmoi]

Ok, reading other answer here, I understand that it may be a good idea to order capture by MVV/LVA and only use SEE to exclude loosing captures from the qsearch. Is this right?

[bob]

What exactly are you doing with SEE? Most significant gain comes from eliminating captures with SEE < 0 from your q-search. That should speed your program up by about 2x (not NPS, but time to search to a fixed depth).

Bob, what is exactly the way to do this? I did as follow: get all moves, then compute a SEE for all captures, then sort, and last qsearch and reject cap see<0. I saw (maybe in Crafty, I dont remember) only calculate SEE when is that move to be searched and initially sort on MVV/LVA.

I implemented some time ago the first and I remember dont getting good results, althought not to reject the implementation.

Here is what I do.

1. generate all capture moves.

2. Sort the moves in simple MVV/LVA order (easy idea is sort_value = captured_piece<<4 + capturing piece)

3. Start searching. As I prepare to search a capture, I ask the following question: "Is the capturing piece less valuable than the captured piece, which is a material winner?" If so, I search it. If the answer is no, I use classic SEE to compute an expected material loss or gain, and if this value is >= 0, I search the move, otherwise I discard it and move to the next one.

The reason for the order of the above steps is to save time. The idea is this. You are going to search in MVV/LVA order as that has been proven to be slightly faster overall than searching in pure SEE order. And since SEE is expensive, you only want to do it when necessary. PxN doesn't need a SEE score, it is not going to lose material according to SEE (which doesn't include pins, overloads, etc). So we only apply SEE when we are not so sure, such as in cases like QxR which might win a rook, or it might lose the queen for the rook, so we want more information before deciding to search that move or not.


Hope that helps.

[bob]

Ok, reading other answer here, I understand that it may be a good idea to order capture by MVV/LVA and only use SEE to exclude loosing captures from the qsearch. Is this right?

yep...

[bob]

Hi,

I've just implemented (for the second time) SEE in my engine and it just doesn't work.

I tested it on this position to a depth of 11 :

If this is the only position where no see works better then see, then it means nothing.

As usual move ordering is based on statistical success, it doesn't mean anything that in a _particular_ position it works worst.

To check a possible bug in SEE I suggest you to go through with a debugger and verify what it really does.

I've not done extensive testing, but I tries at least half a dozen differents positions and I always get similar results. I've not found a position that performs better with SEE than with MVV/LVA.

The problem is, you can use SEE to exclude captures from the q-search. You can't use MVV/LVA for this since it doesn't tell you that QxR is winning a rook vs losing the queen for the rook. If you don't use SEE to reduce the q-search, you are not going to see any advantage at all.

[Kempelen]

Here is what I do.

1. generate all capture moves.

2. Sort the moves in simple MVV/LVA order (easy idea is sort_value = captured_piece<<4 + capturing piece)

3. Start searching. As I prepare to search a capture, I ask the following question: "Is the capturing piece less valuable than the captured piece, which is a material winner?" If so, I search it. If the answer is no, I use classic SEE to compute an expected material loss or gain, and if this value is >= 0, I search the move, otherwise I discard it and move to the next one.

The reason for the order of the above steps is to save time. The idea is this. You are going to search in MVV/LVA order as that has been proven to be slightly faster overall than searching in pure SEE order. And since SEE is expensive, you only want to do it when necessary. PxN doesn't need a SEE score, it is not going to lose material according to SEE (which doesn't include pins, overloads, etc). So we only apply SEE when we are not so sure, such as in cases like QxR which might win a rook, or it might lose the queen for the rook, so we want more information before deciding to search that move or not.


Hope that helps.

And what about normal search? do you something similar or does you "SEEing" all captures and sort them before start the search at move 1?

[Sven]

3. Start searching. As I prepare to search a capture, I ask the following question: "Is the capturing piece less valuable than the captured piece, which is a material winner?" If so, I search it. If the answer is no, I use classic SEE to compute an expected material loss or gain, and if this value is >= 0, I search the move, otherwise I discard it and move to the next one.

One further question on this may be allowed. What you write sounds as if you compute SEE also if value(capturing piece) == value(captured piece), is this right? But you will never discard an equal exchange, so what am I missing here?

Sven

[bob]

Here is what I do.

1. generate all capture moves.

2. Sort the moves in simple MVV/LVA order (easy idea is sort_value = captured_piece<<4 + capturing piece)

3. Start searching. As I prepare to search a capture, I ask the following question: "Is the capturing piece less valuable than the captured piece, which is a material winner?" If so, I search it. If the answer is no, I use classic SEE to compute an expected material loss or gain, and if this value is >= 0, I search the move, otherwise I discard it and move to the next one.

The reason for the order of the above steps is to save time. The idea is this. You are going to search in MVV/LVA order as that has been proven to be slightly faster overall than searching in pure SEE order. And since SEE is expensive, you only want to do it when necessary. PxN doesn't need a SEE score, it is not going to lose material according to SEE (which doesn't include pins, overloads, etc). So we only apply SEE when we are not so sure, such as in cases like QxR which might win a rook, or it might lose the queen for the rook, so we want more information before deciding to search that move or not.


Hope that helps.

And what about normal search? do you something similar or does you "SEEing" all captures and sort them before start the search at move 1?

I use exactly the same idea as above, except that I do not "toss" the SEE < 0 captures, I just defer them until after the good captures, killers, etc.

[bob]

3. Start searching. As I prepare to search a capture, I ask the following question: "Is the capturing piece less valuable than the captured piece, which is a material winner?" If so, I search it. If the answer is no, I use classic SEE to compute an expected material loss or gain, and if this value is >= 0, I search the move, otherwise I discard it and move to the next one.

One further question on this may be allowed. What you write sounds as if you compute SEE also if value(capturing piece) == value(captured piece), is this right? But you will never discard an equal exchange, so what am I missing here?

Sven

I probably just worded it sloppily. Since I use MVV/LVA for ordering (this is not my idea, by the way, others suggested it here last year and I tested and found that it was actually better because it defers the SEE calls, and when you can defer something, sometimes it is never done at all thanks to cutoffs, so it it just an efficiency issue more than anything. In any case, I only use SEE if it is not obvious that the move doesn't lose material. So PxP, BxN, RxR are all considered to be "zero at worst" and do not get a SEE analysis.

[mathmoi]

[...]You are going to search in MVV/LVA order as that has been proven to be slightly faster overall than searching in pure SEE order. And since SEE is expensive, you only want to do it when necessary[...]

Hope that helps.

Hi Robert,

Yes, it helped. It's more clear to me where and how SEE can be used. I was under the impression that ordering captures with SEE in regular search would give me a big speedup. I was wrong.

Thanks,

[mathmoi]

And what about normal search? do you something similar or does you "SEEing" all captures and sort them before start the search at move 1?

I use exactly the same idea as above, except that I do not "toss" the SEE < 0 captures, I just defer them until after the good captures, killers, etc.

You still search them before the non-captures?