Author: Stuart Cracraft
Date: 21:08:15 01/14/06
Go up one level in this thread
On January 14, 2006 at 10:30:19, Robert Hyatt wrote:
>On January 14, 2006 at 01:19:27, Stuart Cracraft wrote:
>
>>On January 12, 2006 at 22:45:04, Robert Hyatt wrote:
>>
>>>On January 11, 2006 at 12:34:42, Stuart Cracraft wrote:
>>>
>>>>On January 10, 2006 at 21:44:30, Robert Hyatt wrote:
>>>>
>>>>>On January 10, 2006 at 16:15:53, Stuart Cracraft wrote:
>>>>>
>>>>>>Hi - my extension credit is calculated for each ply in the search
>>>>>>and stored in several arrays, one for each type of extension.
>>>>>>
>>>>>>The arrays for the given current ply are summed together
>>>>>>
>>>>>> extension=0; // Prove that we must extend. We assume we don't at first.
>>>>>> :
>>>>>> :
>>>>>> AllExt[ply]=ChkExt[ply]+RecapExt[ply]+PawnExt[ply]+OneExt[ply]+ThreatExt[ply];
>>>>>> if (AllExt[ply]>=1.00) extension=1;
>>>>>> else if (ply>0 && AllExt[ply-1]<1.00 && AllExt[ply-1]+AllExt[ply]>=1.00) {
>>>>>> extension=1;
>>>>>> }
>>>>>> else if (ply>1 && AllExt[ply-1]<1.00 && AllExt[ply-2]<1.00
>>>>>> && AllExt[ply-2]+AllExt[ply-1]+AllExt[ply]>=1.00) {
>>>>>> extension=1;
>>>>>> }
>>>>>> if (BM_X != 0.0)
>>>>>> if (bmx) {
>>>>>> AllExt[ply]+=BM_X; extension++; bmext++;
>>>>>> }
>>>>>>
>>>>>>And if extension is "1" after all of this, then we extend by 1 the
>>>>>>current move at the current ply known as 'ply'.
>>>>>>
>>>>>>My questions are:
>>>>>>
>>>>>> I know that Bob Hyatt has used 0.75 as his check extension for many years
>>>>>> and indicates it is a critical factor in throttling runaway check extensions.
>>>>>
>>>>>Not quite. My "check" extension is 1.0. My "one-legal-reply" extension is .75,
>>>>>as is the recapture and mate threat extensions. But normal check is 1.0 until
>>>>>some ply limit is reached, at which point is is reduced to .5 to limit
>>>>>ridiculously deep searches.
>>>>>
>>>>>
>>>>>
>>>>>> My problem is that since I sum as above, setting the credit for CheckExt[ply]
>>>>>> (before the above code) to 0.75 would really be too little of a good thing,
>>>>>> nothing in fact, since I would only extend a check if there is an additional
>>>>>> consideration forcing a full extension and that is not what Bob meant.
>>>>>
>>>>>You are missing another point that is very significant. I am not doing
>>>>>extensions like you. I simply increment "depth" by the amount of the
>>>>>extensions, even if the total is something like .75. That won't cause a deeper
>>>>>search yet, but if a later ply adds just .25 more, then suddenly the search will
>>>>>go one ply deeper. It didn't appear that you are doing it that way. My
>>>>>fractional extensions are carried along, ply by ply, and slowly build up until
>>>>>they cause another ply of depth to be searched...
>>>>>
>>>>
>>>>At which point you then reset the additive to zero so that it can start
>>>>accumulating again?
>>>
>>>
>>>No, it is just added to depth at each ply. And each time I advance one ply, I
>>>subtract 1.0 from depth... For my one ply search, depth starts off at something
>>>like 1.5 (you can look at iterate.c in crafty to see what SearchRoot() is
>>>actually called with, I have changed this more than once). So even a .75
>>>extension will cause the search to go to 2 plies rather than one, since 1.5 +
>>>.75 is 2.25... and since depth is always reduced by 1.0 for each ply, and
>>>sometimes gets incremented by as much as 1.0 in a single ply, the depth carries
>>>the extension amount along all the way until the last call to search drops depth
>>>below 1.0 and no extensions are done at that ply, dropping me to the q-search on
>>>the next ply...
>>
>>Thanks - that was the level of hold-the-hand detail that I needed.
>>
>>I need to change my search parameter depth to a float from an int and
>>implement something and test the effects.
>>
>>So many changes, so little time...
>
>
>I would not use a float. Use an int, where a ply = 60 or some such number. I
>chose 60 so that I can extend by 1/4 (15), 1/3 (20), 1/2 (30), 2/3 (40), 3/4
>(45) and 1 (60). Then I decrement by 60 rather than 1, and everything works
>just fine...
Why don't you use a float and extend by .15, .20, .30, .40, .45 and 1.0?
What is the advantage of avoiding the float? Is runtime processing that much
less efficient for float on architecture X than for an int?
I don't know how many push's onto the stack a float is vs. an int or how
much less efficient a += or -= is for a float vs. an int.
Perhaps these are your considerations.
Just how bad is it?
My program has two modes, one where it returns only integer and the other
where it can return float, for all board evaluation logic and related
within the program. I turn on the int for times I want speed but have always
wondered about this and don't run tests on everything (unfortunately.)
Stuart
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.