SEE is not working for me. Any idea why?

[mathmoi]

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 :

[d]1k1r3q/1ppn3p/p4b2/4p3/8/P2N2P1/1PP1R1BP/2K1Q3 w - -

with MVV/LVA, it gets to ply 11 in 4.19 seconds, with SEE (all captures before normal moves) it gets to ply 11 in 6.17 seconds and with SEE (loosing captures after normal moves, it gets ti ply 11 in 9.92 seconds.

I've tested other positions with similar results.

Of course, SEE values are more long to compute, so my nps is dropping. I expected that. What I did not expected is that the numbers of nodes increased also:

Code: Select all

MVV/LVA : 2.7 millions nodes
SEE (all captures before normal moves) : 3.0 millions nodes
SEE (loosing captures after normal moves) : 5.7 millions nodes

I tried to extract data to see where were the fail high occuring. It seems that the version with SEE have a greater occurence of fail high on the first and second move tried, but the FH/Attempt ratio is much lower on the other moves with SEE than with MVV/LVA.

Honestly, I don't know what to test next. Can theses result be caused by my very simple evaluation function (pieces value + piece_square table)? Have anyone ever seen something like that?

[jwes]

Almost certainly, you have a bug in your implementation. Find a position that gives similar results with a much shallower search, dump the trees, and look for the extra moves that SEE is considering.

[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 :

[d]1k1r3q/1ppn3p/p4b2/4p3/8/P2N2P1/1PP1R1BP/2K1Q3 w - -

with MVV/LVA, it gets to ply 11 in 4.19 seconds, with SEE (all captures before normal moves) it gets to ply 11 in 6.17 seconds and with SEE (loosing captures after normal moves, it gets ti ply 11 in 9.92 seconds.

I've tested other positions with similar results.

Of course, SEE values are more long to compute, so my nps is dropping. I expected that. What I did not expected is that the numbers of nodes increased also:

Code: Select all

MVV/LVA : 2.7 millions nodes
SEE (all captures before normal moves) : 3.0 millions nodes
SEE (loosing captures after normal moves) : 5.7 millions nodes

I tried to extract data to see where were the fail high occuring. It seems that the version with SEE have a greater occurence of fail high on the first and second move tried, but the FH/Attempt ratio is much lower on the other moves with SEE than with MVV/LVA.

Honestly, I don't know what to test next. Can theses result be caused by my very simple evaluation function (pieces value + piece_square table)? Have anyone ever seen something like that?

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).

[Kempelen]

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.

[Sven]

Hi,

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

I assume a bug, too. How do you handle SEE?

I guess you have already read this: http://chessprogramming.wikispaces.com/Static+Exchange+Evaluation

When the only purpose of using SEE is to exclude all losing captures (SEE < 0) from qsearch then it is safe to restrict SEE calculation to those captures with value(capturedPiece) < value(movingPiece), so to all "potentially losing captures" (let's call them PLC here). All other captures, including promotions, can be sorted by MVV/LVA and tried in that order, before trying those PLC which turned out to have SEE >= 0 in the order determined by SEE. Captures with SEE < 0 can be skipped completely (not searched).

This is at least what has been posted here several times, although there are also other ways of dealing with SEE in qsearch. One might as well calculate SEE for all captures, skip SEE < 0, and order everything else based on SEE, so no MVV/LVA in qsearch.

Sven

[Sven]

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.

Although you asked Bob directly I can try to give an answer, too.

I am not sure what you mean exactly by "and last qsearch and reject cap see<0". I assume you include all captures in qsearch.

If you calculate SEE for all captures withing qseach then you can completely exclude those moves with SEE < 0 from being searched at all, i.e. remove them from the list somehow even before sorting. If you do as you have written then tests people have done seem to indicate that you do not save anything with SEE, because the additional effort for SEE computation seems to dominate over the saving returned by better ordering of captures without pruning away the losing ones. But that may vary from engine to engine.

Sven

[mcostalba]

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.

[mathmoi]

Almost certainly, you have a bug in your implementation. Find a position that gives similar results with a much shallower search, dump the trees, and look for the extra moves that SEE is considering.

Good idea, I don't know why I did not though about that. Thanks.

[mathmoi]

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).

I use for

1) eliminate loosing captures in qsearch
2) ordering capture in regular and qsearch
3) delaying loosing captures after normal moves in regular search.

Maybe I should try with only 1) first.

[mathmoi]

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.