Author: Robert Hyatt
Date: 11:44:54 01/16/06
Go up one level in this thread
On January 16, 2006 at 13:09:37, Stuart Cracraft wrote:
>On January 15, 2006 at 11:27:06, Robert Hyatt wrote:
>
>>On January 15, 2006 at 00:08:15, Stuart Cracraft wrote:
>>
>>>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?
>>
>>
>>First, floats have an accuracy problem. For example, convert .1 to IEEE and
>>you'll see what I mean. That makes testing/debugging a bit more complicated
>>when _you_ add up the extensions and get 1.0, but the hardware adds them up and
>>gets .9999997 and doesn't extend.
>>
>>Second, It is easier to store the rightmost N bits of an int as the "draft" in a
>>hash table. For a float, you have to store the entire 32 bits.
>>
>>Finally, speed. int math is as fast as it gets. floating adds are not that
>>bad, but if you look at the X86 architecture, doing the test "if (depth >= 1.0)
>>is a real mess if you do it in FP. You do the FP compare, then take the FP
>>status word to AX and then do a compare there to do the conditional jump. That
>>is too complicated and too slow.
>>
>>
>>
>>
>>
>>>
>>>What is the advantage of avoiding the float? Is runtime processing that much
>>>less efficient for float on architecture X than for an int?
>>
>>See above. The answer is yes. :)
>>
>>
>>
>>>
>>>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.
>>>
>>
>>floating point math is slower, but the comparisons are ugly, and the inaccuracy
>>and other issues above simply made me discard the idea before I even got
>>started.
>>
>>
>>
>>
>>
>>>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
>>
>>If you can fit your scores in the 2^31-1 to -2^31 range, you can easily convert
>>that to a float anyway. If you want to display scores like that. I don't
>>convert to floats in Crafty, but I do display score (int in centipawns) as a
>>float by something like this:
>>
>>printf("%d.%2d", score/100, score%100);
>
>I'm sold. I'll be converting to a depth += DEPTH type methodology at
>some point where depth is 64x the depth provided in the search routine
>and DEPTH is things like 16, 32, 48, 64, etc.
>
>Thanks,
>
>Stuart
Just remember to pick N so that you can get the fractions you expect to want
_exactly_. I use 60, so that I can get 1/4, 1/3, 1/2, 2/3, 3/4 exactly. I
suppose one could make a case for 100, so that you could extend in 1/100ths,
although you could not do 1/3 and 2/3 exactly...
That's where 60 came from, as I wanted to test at least 2/3, 3/4 and 1, and 60
gave me that with other options possible also...
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.