Odd/even iterations in the selektive search

[JensBNielsen]

What I do is ask the question "will this capture (which means material gain) bring the score back to at least the alpha bound score?" If the answer is yes, then I search it. Now how I answer the "will this capture...." question is a bit more complex as I use what is called a SEE or Static Exchange Evaluator to evaluate captures on a single square to see if the initial capture wins or loses material. I use this score added to the current real material score and compare that to the current alpha bound. if SEE(move) + MaterialBalance < alpha, forget searching that move.

Thanks.... Seems both logical and easy )

[Don]

Jens,

You should get the quies search working before you start experimenting with static exchange evaluators. For years most programs did fine without static exchange evaluators.

When you get the quiest working correctly then you should definitely look at static exchange as the next improvement, it's an important modern enhancement to the search.

It seems like you are probably still doing something wrong. Do you have the standard quies move ordering?

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

Thanks. I have now made a better quiescence search (see below).

It is still slow; though, as I try all captures.
I must change it to only try sufficient recaptures where it is relevant.

But how do you determine when it is a sufficient recapture?
Is it when the materiel balance matches the score achieved in the previous iteration....?




Dabbaba:
1 00:00 164 164 -0,53 h4h5 score: -53 v=-53 pawn=47 mat=-100 n=164 time=0.00
1 00:00 191 191 -0,42 g2g4 score: -42 v=-45 pawn=55 mat=-100 n=191 time=0.00
2 00:00 300 300 -0,43 g2g4 score: -43 v=-282 pawn=-182 mat=-100 n=300 time=0.00
2 00:00 1.884 1.884 -0,21 h4h5 score: -21 v=-53 pawn=47 mat=-100 n=1884 time=0.00
3 00:00 8.602 8.602 +3,03 h4h5 score: 303 v=-42 pawn=58 mat=-100 n=8602 time=0.00
4 00:00 27.084 677.100 -0,47 h4h5 score: -47 v=-76 pawn=24 mat=-100 n=27084 time=0.04 N/S=677100
4 00:00 29.112 727.800 -0,37 e1d2 score: -37 v=-61 pawn=32 king=7 mat=-100 n=29112 time=0.04 N/S=727800
5 00:00 42.826 611.800 -0,60 e1d2 score: -60 v=9 pawn=102 king=7 mat=-100 n=42826 time=0.07 N/S=611800
5 00:00 62.215 777.687 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=62215 time=0.08 N/S=777688
6 00:00 90.340 694.923 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=90340 time=0.13 N/S=694923
6 00:00 110.206 688.787 0,00 e1d1 score: 0 v=-97 pawn=3 mat=-100 n=110206 time=0.16 N/S=688788
7 00:00 163.951 655.804 +7,36 e1d1 score: 736 v=-102 pawn=-2 mat=-100 n=163951 time=0.25 N/S=655804
8 00:00 231.388 642.744 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=231388 time=0.36 N/S=642744
9 00:00 428.595 621.152 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=428595 time=0.69 N/S=621152
10 00:02 909.692 645.171 +7,43 e1d1 score: 743 v=-97 pawn=3 mat=-100 n=909692 time=1.41 N/S=645172

1 00:00 5 5 +0,02 (hash: write=87259 nowrite=1493278 pre-va=1031303 pre-va-hit=691679
1 00:00 5 5 +0,02 (hash: error=0 nofinal(cut-off!)=8824 read=1394625 read_ok=719136 read_ok_final(same position met again)=1216
1 00:00 5 5 +0,02 (hash-elementer: max=524287 used=47666 used-pct=9.1 - VERSION 2.08 JA-Pelle Date 18-07-2009
1 00:00 5 5 +0,02 e1d1 a4b3 d1c1 f6f5 g2g3 b3c3 h4h5 c3d4 h5h6 d4e4 h6h7 f5f4 g3f4 f7f5

[Don]

There is another thing you can try before getting in to the see() stuff. It's not quite as good as see() but it's not bad and is a step beyond mvv/lva.

In the quies you can view all up-captures naturally as good. Ditto with even captures, they cannot lose. Treat them all the same as any modern program does ordering them by mvv/lva.

So the only issue is with down-captures and how to handle them.

With down captures, the most common case is where the victim is defended by his own pawn - and that happens to be the easiest to test for. So RxN is bad if the knight is defended. Throw it out in the quies search. In the main search you may want to put it after the other captures regardless of mvv/lva.

You can take this one step farther with knight attacks, since they are easy to detect too. So QxR defended by a knight is bad (whether the knight is eventually subject to capture or not.) NxP defended by knight is NOT necessarily bad, so you probably should not assume it is since you are not doing the full blown analysis to see if the enemy knight is subject to capture.

You won't catch all the cases that see() is so good at detecting, but on the other hand this IS safer so even though it's not quite as good in the long run, it isn't that bad either.