Computer Chess Club Archives




Subject: Re: MTD(f) and hash table size

Author: Uri Blass

Date: 01:36:26 08/17/03

Go up one level in this thread

On August 17, 2003 at 04:27:06, Rudolf Huber wrote:

>On August 16, 2003 at 17:17:26, Tord Romstad wrote:
>>The last few weeks I have been experimenting with MTD(f).  It still does not
>>work quite as well
>>as my old aspiration alpha beta search, but I intend to keep working on it for
>>some more time.
>>Another problem is that MTD(f) has very weird effects when combined with the
>>various forward
>>pruning techniques I use.  This is not entirely unexpected, because I use the
>>values of alpha
>>and beta for pruning decisions.  When I replace plain MTD(f) (which I haven't
>>been able to
>>make work very well; too many researches) with MTD(f) with a convergence
>>accelerator, I
>>often get entirely different search results for the same position.  If I remove
>>all selectivity
>>(except null move pruning) from my search, changing the test driver does not
>>have any
>>effect on the search results, but then my program becomes much too slow.  I
>>suppose I
>>will have to work out new forward pruning techniques.
>First scan you source files for occurences of alpha and beta. If you
>find any look hard and try to understand what you are doing there. In
>mtd(f) there ist NO alpha and NO real beta. All the things (lazy eval?)
>you do with alpha and beta are most likely wrong. Use the last score instead.
>Also I think it is a good idea to keep it simple. Why not disabling
>forward pruning and your "convergence accelerator" and first try to make
>your mtd(f) implementation better than negascout.

The target is not to do something better than negascout but something better
than the previous program.

I see no reason to use mtd(f) if it does not help to be better than the previous


This page took 0.01 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.