Author: Dann Corbit
Date: 21:36:12 07/27/04
Go up one level in this thread
On July 28, 2004 at 00:30:26, Stuart Cracraft wrote: >Correction -- I was mistaken. I was using the wrong test and >mixed results. > >With a fixed set of 30 test positions (Reinfeld, WAC, 1-30), >MTDF and PVSNEGASCOUT compare in this way at 1 second per move: > >MTDF >**** 90% 27/30 25.69 6640618 221354/1/258440 0/0/307973/0/0/0 > >PVSNEGASCOUT >**** 90% 27/30 25.56 6877388 229246/1/269110 0/0/316245/0/0/0 > >1st number refers to %-correct >2nd pair 27/30 refers to number correct against total >3rd floating point refers to time in seconds >4th number refers to grand total nodes searched >5th triple is ave nodes searched per test position / average time per position > rounded up / average nodes per second during set >6th hextuple refers to some extensions that are used identically in both > >The above MTDF uses the PVSNEGASCOUT for its calls to a search routine. > >This is good considering I knew next to nothing about MTD(f), implemented >it yesterday just copying Aske's code, and got a good tip from Tony and >threw it in. > >Now for the meat. Anyone have something to really make this MTD(f) shine? >I understand 5-15% is the expected improvement in tree size reduction? >Is that all? Play with the granularity of the search. If a pawn is worth 64 centipawns you will do far less searches than 1000 centipawns. But then you lose resolution. So the trick is to find a happy medium, I would guess.
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.