Author: GeoffW
Date: 04:01:50 10/18/04
Hi I have been experimenting with the SEE code in my program. I had not had great results with it previously so thought I should revisit it. I was fairly sure that it was bug free as it seemed to noticeably reduce my node count but the extra time it took to calculate seemed to about break even. Anyway looking at it again, I am using it now in 3 ways, I thought what I am currently doing is fairly standard practice ? 1) I am using SEE to order the capture moves in my Q search. Move ordering in the normal search is still MVVLVA as my SEE is quite slow 2) I am using the SEE score for a capture to prune moves at generation time Bit of pseudoCode addMoveToMoveList() { #ifdef USE_SEE if (scoreBasedOnSee(sideToMove,from,to) < 0) return; #endif etc.......... 3) In my quiesce() routine I have /* material balance is always positive for side to move if that side is up in material */ materialBalance = evalMaterialOnly(); for (i = firstMove[ply]; i < firstMove[ply + 1]; ++i) { /* if we are down on material then we can prune off these quiescent moves fairly safely as the SEE score plus material is still worse than a previous move denoted by alpha */ if ((S32)gen_dat[i].seeScore + materialBalance < alpha ) continue; } etc...... makemove() then quiesce() recurse again The results I have got so far with these 3 sections of code seemed promising as I was managing to search deeper, but my results in games appears to be noticeably worse. I suspect the 3rd code snippet is what is making my program worse although I am not really sure. Is that < alpha pruning just plain wrong or maybe just too severe, should I have a constant additional safety margin added on top ? Any thoughts appreciated, thanks Regards Geoff
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.