During last night's Online blitz I became a little frustrated with the depth Jabba was achieving - somtimes, on a 2.4ghz Processor with 500kns, it failed to get past depth 5 in 10s. Mostly playing at depth 6. The game it won was pure luck vs Micromax - MM was winning hands down until its skeleton eval let it down.
So I've spent the past 6 hours checking through lots of data, and can't find what is wrong - I was assuming move ordering is to blame.
I've disabled Hash table, null move, PVS so it's a pure alpha beta searcher with nothing else.
Here's the bottom of the move loop, with the stats being collected:
Code: Select all
gen_all_moves(game, mat, mlist, hashmove);
uint *list = mlist.p2list(game.getply());
int val = -matescore;
uint played = 0;
uint bestmove = NULLMOVE;
uint from;
int old_alpha = alpha;
if(check && game.getply()==0) { stats->checkext++; depth++; }
for(uint i = 0; i < mlist.getcount(game.getply()); ++i)
{
picknext(i,mlist);
if (makemove(game,mat,his,list[i]))
{
takemove(game,mat,his);
continue;
}
check = incheck(game,mat,game.getside());
ext = 0;
if(check) { stats->checkext++; ext = 1; }
val = -alphabeta( -beta, -alpha, depth-1+ext, true, check);
takemove(game,mat,his);
if(status->stopped == STOPPED) { return 0;}
played++;
from = FROM(list[i]);
if (val > alpha)
{
bestmove = list[i];
if (val >= beta)
{
if(played==1) stats->fhf++;
else stats->fh++;
mlist.score_killer(bestmove, val, game.getply());
mlist.scoremove(list[i], depth, game.getpiece(from));
return beta;
}
alpha = val;
pvupdate(list[i]);
}
}
if (played == 0)
{
if (check)
{
return -matescore + game.getply();
}
else
{
return 0;
}
}
return alpha;
Code: Select all
logger.file<<"\nfh "<<stats->fh;
logger.file<<" fhf "<<stats->fhf<<" ordering ";
p = percent(stats->fhf, stats->fhf+stats->fh);
logger.file<<" "<<p<<"%";
Code: Select all
double percent(int tester, int all)
{
double t = double(tester);
double a = double(all);
if(t==0 || all==0) return 0;
else return (t/a)*100;
}
[d]
I get...
Code: Select all
32.184-->1:position fen r2qkb1r/pp1n1ppp/2p2n2/3pp2b/4P3/3P1NPP/PPPN1PB1/R1BQ1RK1 b kq e3 0 8
32.184-->1:go infinite
32.184<--1:info depth 1 score cp -4 time 0 nodes 253 pv d7c5
32.199<--1:info depth 2 score cp 6 time 0 nodes 827 pv d7c5 e4d5
32.214<--1:info depth 3 score cp 4 time 31 nodes 9087 pv f8d6 e4d5 f6d5
32.246<--1:info depth 4 score cp -6 time 62 nodes 26161 pv f8d6 e4d5 f6d5 d2e4
32.401<--1:info depth 5 score cp 1 time 218 nodes 106314 pv f8d6 g3g4 h5g6 g4g5 f6h5
34.148<--1:info depth 6 score cp 3 time 1965 nodes 861491 pv f8d6 e4d5 c6d5 g3g4 h5g6 f1e1
45.132<--1:info depth 7 score cp 6 time 12948 nodes 5451271 pv f8d6 e4d5 c6d5 g3g4 h5g6 g4g5 f6h5
85.488-->1:stop
85.535<--1:nulltry 0 nullcuts 0 0%
85.535<--1:hashcuts 0
85.550<--1:fh 63022 fhf 1785053 ordering 96.5899%
85.550<--1:nodes 2685071 qnodes 21505905 88.9005%
85.550<--1:qcuts 0
85.567<--1:checkext = 507211 pawnseventh = 106305 intopawnend = 0
85.567<--1:pvssearch = 0 pvsresearch = 0 0%
85.567<--1:bestmove f8d6
I'm afraid this can't be... I've been butchering various OS engines this morning to make them pure AB searchers, no pruning, no null, no hash, no extension apart from check and comaparing the stats.
Most get around 90% fail high first, and similar % of Q nodes, but reach deeper depths far easier than Jabba.
For example, Fruit 1.0 , Diablo 0.4 end up typically 2 ply deeper after 60s with Ordering 90-92% and Q nodes around 90%. Jabba sits way behind, with a theoretically much better ordering.
Which means there is a bug somewhere, but I'm getting very frustrated in wondering where to look.
Any ideas?
Thanks
Richard
PS It's tough at the bottom
