Problems with SEE

[Desperado]

...I'm also gonna experiment with SEE pruning in QS, which seems to be a very big loss for me, oddly enough....

Code: Select all

            if(!Pos::easy_capture(pos, cMove)) {
                if&#40;Pos&#58;&#58;see&#40;pos, cMove&#41; < 0&#41; &#123;
                    continue;
                &#125;
            &#125;

QS is of course much more time sensitive, therefor you should try to avoid SEE for easy captures (attacker value <= captured value)

[ZirconiumX]

...I'm also gonna experiment with SEE pruning in QS, which seems to be a very big loss for me, oddly enough....

Code: Select all

            if(!Pos::easy_capture(pos, cMove)) {
                if&#40;Pos&#58;&#58;see&#40;pos, cMove&#41; < 0&#41; &#123;
                    continue;
                &#125;
            &#125;

QS is of course much more time sensitive, therefor you should try to avoid SEE for easy captures (attacker value <= captured value)

Yeah, that's similar to what's currently being tested.

Code: Select all

        if (att >= def) {
            return mvvlva+24000; // Winning or equal capture
        } else {
            int see_score = SEE(...);
            if (see_score >= 0) {
                return mvvlva+24000;
            }
            return mvvlva-4000; // Losing capture
        }

But as a move ordering score.

Code: Select all

Score of New vs Old: 169 - 156 - 106  [0.515] 431

It's kinda a wash though.

[Desperado]

...I'm also gonna experiment with SEE pruning in QS, which seems to be a very big loss for me, oddly enough....

Code: Select all

            if(!Pos::easy_capture(pos, cMove)) {
                if&#40;Pos&#58;&#58;see&#40;pos, cMove&#41; < 0&#41; &#123;
                    continue;
                &#125;
            &#125;

QS is of course much more time sensitive, therefor you should try to avoid SEE for easy captures (attacker value <= captured value)

Yeah, that's similar to what's currently being tested.

Code: Select all

        if (att >= def) {
            return mvvlva+24000; // Winning or equal capture
        } else {
            int see_score = SEE(...);
            if (see_score >= 0) {
                return mvvlva+24000;
            }
            return mvvlva-4000; // Losing capture
        }

But as a move ordering score.

Code: Select all

Score of New vs Old: 169 - 156 - 106  [0.515] 431

It's kinda a wash though.

Well, i think you should not invest time for move ordering in qs for moves that you want to prune. You can prune the move whenever it occures, you don't need to shift it to the end of the list.

You can save more time when you do the check just when the move is picked, because there can be a cut before.

So, if you think about "pruning" the move because of a bad SEE, you should do the test when the move is picked imo. That might be different if you want to search the move for some reasons.

[Sven]

Code: Select all

        if (att >= def) {
            return mvvlva+24000; // Winning or equal capture
        } else {
            int see_score = SEE(...);
            if (see_score >= 0) {
                return mvvlva+24000;
            }
            return mvvlva-4000; // Losing capture
        }

As also noted by Michael, I would not use SEE as part of the initial move scoring since that would require to unconditionally call it for several moves even if they would never actually be searched (due to an earlier cutoff). As a first step I think that using SEE in QS to prune losing captures (restricted to higher x lower captures) should already be sufficient to see an improvement over pure MVV/LVA. In a second step SEE could also be used to postpone losing captures (and possibly losing quiet moves).

In Jumbo I do both steps (only for captures higher x lower) but not exactly with SEE but with something that is both faster and less accurate. Replacing it by SEE is on my todo list.

What about your 'att' and 'def' values, how do you handle bishop and knight in this case? Would att=knight + def=bishop trigger an SEE() call?

[hgm]

Note that when SEE is only used to postpone/prune when it is negative, and the actual value is not used, you can do a null-window SEE.

[ZirconiumX]

First of all, my apologies for the delay - real life has been a bit hectic recently.

As also noted by Michael, I would not use SEE as part of the initial move scoring since that would require to unconditionally call it for several moves even if they would never actually be searched (due to an earlier cutoff).

My logic behind that was that it would be an optimisation to postpone the SEE until it is searched because it would not have an effect on the final ordering. I wanted to check the basic idea was sound before trying to improve it.

As a first step I think that using SEE in QS to prune losing captures (restricted to higher x lower captures) should already be sufficient to see an improvement over pure MVV/LVA.

The test is still running, but:

Code: Select all

Score of SEEPrune vs MVVLVA: 116 - 133 - 104  [0.476] 353

I would not call that an improvement so far. However, I get a 36% node count reduction even with a 15% NPS reduction. So it's definitely doing something. It's just not doing enough.

In a second step SEE could also be used to postpone losing captures (and possibly losing quiet moves).

Mmm, though I do think we should get step 1 working before step 2.

In Jumbo I do both steps (only for captures higher x lower) but not exactly with SEE but with something that is both faster and less accurate. Replacing it by SEE is on my todo list.

Because Dorpsgek keeps incrementally updated attack tables, I could easily run a defender check and perhaps Hx defended L to later in the list. It's not a SEE, but it's something, and it's fast.

What about your 'att' and 'def' values, how do you handle bishop and knight in this case? Would att=knight + def=bishop trigger an SEE() call?

Yes, it would. I can try to special-case it in this situation. Might be worth a test.

[hgm]

Because Dorpsgek keeps incrementally updated attack tables, I could easily run a defender check and perhaps Hx defended L to later in the list. It's not a SEE, but it's something, and it's fast.

This is what I refer to as BLIND: Better or Lesser If Not Defended. It is almost as good as SEE. Deep SEE is very unreliable, as most moves have side effects that are not considered. The important thing is really whether you can gobble up unprotected material with your strong pieces.