Author: Robert Hyatt
Date: 07:33:12 11/11/03
Go up one level in this thread
On November 11, 2003 at 10:24:30, José Carlos wrote:
>On November 11, 2003 at 09:38:59, Robert Hyatt wrote:
>
>>On November 11, 2003 at 02:45:28, José Carlos wrote:
>>
>>>On November 11, 2003 at 01:00:14, John Stanback wrote:
>>>
>>>>As others have noted, this is an interesting position since the tree
>>>>becomes so much smaller after the capture such that it's easy
>>>>to enough search depth to see the impact of Qxf3.
>>>>I made a simple modification that lets Zarkov find Qxf3 in
>>>>under a minute (or less depending on the threshold). This also helps
>>>>on lots of other sacrifice positions, but I don't know
>>>>if overall it helps more than it hurts since I just implemented
>>>>it 15 minutes ago.
>>>>The extra code is only applied at the root and looks like this:
>>>>
>>>>MakeMove();
>>>>d = depth;
>>>>while (1)
>>>> {
>>>> score = -Search(side,ply,d,-beta,-alpha);
>>>> if (!capture || nodes_just_searched > threshold)) break;
>>>> ++d;
>>>> }
>>>>UnmakeMove();
>>>>
>>>>Where threshold is some fraction of the total nodes searched
>>>>during the previous iteration, say nodes/32 or nodes/16.
>>>>
>>>>This allows the program to search captures at the root to
>>>>arbitrary depth. In this position for example, it searches
>>>>Qxf3 to more than 20 ply during iteration 11!
>>>>
>>>>It doesn't seem to cause much slowdown on about 20 other positions
>>>>I tried. I think this might cause some strangeness with the hashtable.
>>>>It may make sense to try some variant of this at ply=2 also.
>>>>
>>>>
>>>>John
>>>
>>>
>>> Interesting idea. What about real games? In games, I don't clear the hash
>>>table between moves, so if I did this (haven't tried 'cause I'm at work now) I
>>>guess I'd have extrange behaviour when I'd cuoff by hash hit in the first
>>>iterations. I mean, if I search up to depth 12, in the next move I go to depth
>>>10 almost instantly due to hash hits in ply 2.
>>> Do you preserve the hash table between moves? Have you tried games to see how
>>>your idea affects?
>>>
>>> José C.
>>>
>>
>>I don't see where this should hurt hashing at all. You are only searching
>>the positions below the capture with extra depth. Certainly storing the
>>depth you are using when you do the search can't hurt later lookups no matter
>>where they occur...
>
> I'm not sure if what I say makes sense because I haven't come back home yet to
>try it, but the idea is: I have made a search before; then my oponent moves and
>I start searching again, depth = 1; and I do
>
>MakeMove();
>d = 1;
>while (1)
> {
> score = -Search(side,ply,d,-beta,-alpha);
> if (!capture || nodes_just_searched > threshold)) break;
> ++d;
> }
>UnmakeMove();
>
> I will hit the hash table in ply 2 with draft, lets say, 10, so I'll return
>with a very small number of nodes searched; then I ++d and try again; at some
>point, I won't be able to cutoff from the hash table and I'll start searching at
>a high depth; if time runs out, I will have only searched on move.
>
> José C.
OK... that I agree with. I was talking about "wrong results from hashing"
which should not happen. But searching root moves to different depths is
certainly dangerous if you don't have a short time-out set for those
fake searches, which could be used to solve _this_ particular problem of
course.
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.