Small code tidy up and test results

When testing at 1'+0" time control results are still
reasonably good. We have made two sessions on two
different PC.

After 840 games Mod - Orig: +221 -194 =425 +10 ELO (two CPU)

After 935 games Mod - Orig: +246 -222 =467  +9 ELO (single CPU)

So it seems that with fast CPU and/or longer time controls
benefits of the patch are a bit reduced. This could be due
to the fact that only 3% of nodes are pruned by razoring at
depth one and these nodes are very swallow ones, mostly get
pruned anyway with only a slightly additional cost, even
without performing any do_move() call.

Another reason is that sometime (0,3%% of cases) a possible
good move is missed typically in positions when moving side
gives check, as example in the following one

3r2k1/pbpp1nbp/1p6/3P3q/6RP/1P4P1/P4Pb1/3Q2K1 w - -

The winning move Rxg7+ is missed.

Bottom line is that patch seems good for blitz times, perhaps
also for longer times. We should test against a third engine
(Toga ?) to have a final answer regarding this new setup.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This commit is contained in:
Marco Costalba
2009-04-19 17:23:30 +01:00
parent d20e0cf048
commit bd26374f21
2 changed files with 10 additions and 23 deletions

View File

@@ -128,10 +128,6 @@ namespace {
o["Selective Plies"] = Option(7, 0, 10);
o["Futility Pruning (Main Search)"] = Option(true);
o["Futility Pruning (Quiescence Search)"] = Option(true);
//o["Futility Margin (Quiescence Search)"] = Option(50, 0, 1000);
//o["Futility Margin Scale Factor (Main Search)"] = Option(100, 0, 1000);
//o["Maximum Razoring Depth"] = Option(3, 0, 4);
//o["Razoring Margin"] = Option(300, 150, 600);
o["LSN filtering"] = Option(true);
o["LSN Time Margin (sec)"] = Option(4, 1, 10);
o["LSN Value Margin"] = Option(200, 100, 600);