Author: Ratko V Tomic
Date: 06:24:03 10/23/01
Go up one level in this thread
>>distance-to-mate is implicit in the best-move table, it just >>takes a bit of calculation > >That was my point. A normal EGTB hit is the end of the work. This >will require another 100 EGTB reads if it is a mate in 50. That >would absolutely crush performance and weaken the program to the point >it would be far stronger without the EGTB's that have to be used like that. > After you follow through with these 100 reads you have computed automatically the 100 distance-to-mate values, not just the one which is the farthest from the mate. Since these are more relevant for the game you're playing than general purpose distance-to-mate values, one would keep the "wasted" 99 values in expanded form, 1 lookup away. They'll likely turn up in the searches shortly. So, you're roughly getting one distance-to-mate value per one lookup, except that lookups are batched up, you can't just do one at a time. Considering the reduced memory paging effect of batching up similar tasks, it may end up gaining not losing the time (just as buying groceries for the rest of the week, while you're there, saves you time & cost compared to buying only what you need at the moment; it's the special case of the economy of concentration of efforts/specialization). Considering also that using the best-move you may be able to fit couple times more table information on any given disk or RAM size you have available, it is less than obvious that distance-to-mate has any advantage at all (and it may well be worse) regarding the net playing strength.
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.