Problems with SEE

[ZirconiumX]

So, considering the "Check extension vs LMR", I blew the dust off my two previous SEE implementations - one based on the REBEL SEE table, and one based on the CPW SEE table - and added them back to my program Dorpsgek. I also ported the CPW X-ray update code to the SEE table to test if the added accuracy made any difference to the elo.

TC: 10+0.1
Main change is purely the capture ordering - I don't defer losing captures, or prune bad SEE moves in QS, because I think that would be an unreasonable comparison to MVV/LVA, which cannot prune such moves.

Code: Select all

Rank Name                          ELO   Games   Score   Draws
   1 MVVLVA                        156     400     71%     26%
   2 REBEL-SEE                     -92     100     37%     32%
   3 REBEL-SEE-XRay                -92     100     37%     28%
   4 CPW-SEE                      -230     100     21%     24%
   5 CPW-SEE-XRay                 -230     100     21%     22%

I realise 100 games is not the most scientific, but the elo difference is big enough to be significant. I can run more if needed.

I have uploaded the code here if anybody wishes to read it - I'd be happy to explain parts of the code.

[hgm]

How exactly do you use SEE? You order by victim value if attacker >= victim, and by SEE if attacker < victim?

[ZirconiumX]

How exactly do you use SEE? You order by victim value if attacker >= victim, and by SEE if attacker < victim?

No, I always use SEE for captures.

I realise that doing SEE for all moves is inefficient, but being able to order the moves knowing exactly the capture sequence outcome should result in a lower branching factor, right?

Except in my case, the CPW SEE node count quadruples compared to MVV/LVA, and the REBEL SEE node count is slightly less than the MVV/LVA count, but not enough.

[hgm]

Knowing something never changes the result. It depends on how you use the knowledge. Calculating SEE for every capture won't do anything (other than wasting time) when you would still sort the captures in the same order as without using SEE.

So the question is, how do you use the SEE values?

[ZirconiumX]

Knowing something never changes the result. It depends on how you use the knowledge. Calculating SEE for every capture won't do anything (other than wasting time) when you would still sort the captures in the same order as without using SEE.

So the question is, how do you use the SEE values?

Main change is purely the capture ordering - I don't defer losing captures, or prune bad SEE moves in QS, because I think that would be an unreasonable comparison to MVV/LVA, which cannot prune such moves.

The SEE scores are used for move ordering in both QS and AB.

Sure, I could enable things like QS SEE pruning etc, but that's not going to help test the question "Is SEE better than MVV/LVA for capture ordering?", is it?

In any case, I'll queue up tests for using it, if that will set your mind at ease.

[hgm]

The SEE scores are used for move ordering in both QS and AB.

But how are they used? If you would sort all captures by SEE score... That is well known to be no good.

[Robert Pope]

The SEE scores are used for move ordering in both QS and AB.

But how are they used? If you would sort all captures by SEE score... That is well known to be no good.

Okay, so that's what I am doing in my program. What's the right way?

[hgm]

Only use SEE on high x low captures, to replace the victim value as sort key. Low x high or equal captures of a higher victim should have priority over capture of lesser victims. Because they gain more if the opponent does not recapture, and you almost always can collect the SEE value on the lesser victim afterwards when he does. While if you start working on the lesser victim while the higher one is still around, the opponent starts to try all kinds of nastiness with the latter, blowing up the tree. (Note that when you can play RxR or QxQ, he will be able to play it too. Your SEE value of these captures may be 0 because they are protected, but your R or Q might very well be unprotected.)

[Desperado]

The SEE scores are used for move ordering in both QS and AB.

But how are they used? If you would sort all captures by SEE score... That is well known to be no good.

Okay, so that's what I am doing in my program. What's the right way?

Hi,

you can use SEE to move losing moves (not only captures) to the end of the movelist). So, when the moves are sorted by mvv/lva already and they are picked, you can delay the search by moving them to the end.

Then,within the "bad" (end of the) movelist they are automatically ordered too.

Well, the order is now by mvv/lva, but SEE filters losing captures and does not use the SEE value to sort something.

[ZirconiumX]

The SEE scores are used for move ordering in both QS and AB.

But how are they used? If you would sort all captures by SEE score... That is well known to be no good.

Okay, so that's what I am doing in my program. What's the right way?

Hi,

you can use SEE to move losing moves (not only captures) to the end of the movelist). So, when the moves are sorted by mvv/lva already and they are picked, you can delay the search by moving them to the end.

Then,within the "bad" (end of the) movelist they are automatically ordered too.

Well, the order is now by mvv/lva, but SEE filters losing captures and does not use the SEE value to sort something.

This, I think was one of the keys.

It's not earth shattering, but using SEE only to defer captures is about 10-20 elo:

Code: Select all

Score of SEE-Defer vs current: 118 - 103 - 76  [0.525] 297

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