Author: Ross Boyd
Date: 15:48:35 04/18/05
Go up one level in this thread
On April 18, 2005 at 07:24:11, Uri Blass wrote: >On April 18, 2005 at 05:57:41, Ross Boyd wrote: > >>>>>Which makes me think a low legal move count would be a better indicator of when >>>>>to avoid null moving, rather than the usual "if (total_side_to_move_pieces < x)" >>>>>condition. I think Movei generates legal moves and so is able to use this >>>>>method. >>>>> >>>>>Food for thought, >>>>> >>>>>Ross >>>> >>>>Yes >>>> >>>>Movei is using that method but unfortunately it cannot solve it in a reasonable >>>>time probably because of other tricks that I use that may help in games but not >>>>at test suites. >>>> >>>>Latest Movei does not see the mate at depth 17 and the branching factor from >>>>depth 14 is very bad. >>>> >>>>It needs >>>>20490 nodes to finish depth 14. >>>>234720 nodes to finish depth 15. >>>>3524639 nodes to finish depth 16. >>>>54218505 nodes to finish depth 17. >>>> >>>>Uri >> >>Hmmm... that's a lot of nodes... if I recall correctly you don't do hash table >>cuts, so that might explain the low depth. TRACE doesn't solve it either, and >>gets to ply 40 almost instantly with a draw score only. If I switch off null >>move, then it takes about 12 seconds (P3-600) to find the mate. Not sure now >>what depth was needed. >> >>Ross > >The problem for movei is certainly not null move pruning because null move >pruning is not used when the number of moves of the side to move is small. > >part of the problem is check extensions and part of the problem is probably >pruning based on evaluation together with other factors that I should improve. > >Note that pruning based on evaluation made movei weaker in test suites but >stronger in games. > >Uri That's interesting about the test suite results. Last night I ran the ECMGCP test suite at 30 secs on a P3-600. Latest 1.34alpha scored 142/183. Compare that with Ruffian 1.0.1 which scored 134/183 on same hardware. Clearly, Ruffian is 200+ ELO stronger, so it just shows the importance of eval/search/pruning and also not to measure strength with testsuites. I'm keen to experiment more with reductions in the main search. Currently, TRACE only uses nullmove and hash table cuts (hash cuts can introduce errors but it certainly improves speed, more experiments needed) to prune in the main search. Ross
This page took 0 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.