Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: MTD(f)

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.