Author: José Carlos
Date: 23:51:15 08/09/01
Go up one level in this thread
On August 09, 2001 at 12:44:40, Andrew Williams wrote:
>On August 09, 2001 at 11:17:56, Dieter Buerssner wrote:
>
>>On August 09, 2001 at 11:02:38, Andrew Williams wrote:
>>
>>>On August 09, 2001 at 10:48:18, Dieter Buerssner wrote:
>>>
>>>>On August 09, 2001 at 10:05:42, Andrew Williams wrote:
>>>>
>>>>>Here's my implementation of this in PostModernist:
>>>>>
>>>>>if(ply < (DEPTH-3)) {
>>>>> int m;
>>>>>
>>>>> for(m=plystart[ply]; m < plystart[ply+1]; m++) {
>>>>> make_move(tree[m].mv);
>>>>> if(in_check(OTHERSIDE(whoseTurn))) {
>>>>> unmake_move();
>>>>> continue;
>>>>> }
>>>>> // Probe the TT. If found, react appropriately!
>>>>> ttr = tt_probe();
>>>>> if(ttr != NULL) {
>>>>> if(beta <= -ttr->beta && ttr->betaDraft >= (draft-1)) {
>>>>> unmake_move();
>>>>> return -ttr->beta;
>>>>> }
>>>>> }
>>>>> unmake_move();
>>>>> }
>>>>>}
>>>>
>>>>Perhaps, I don't understand this correctly. Don't you ignore all possible search
>>>>extensions, that might be triggered by the move here.
>>>>
>>>>Or is the "if(in_check(OTHERSIDE(whoseTurn)))" taking care of the check
>>>>extension. (I am not totally sure, whose turn it is ...) It could also mean,
>>>>that this is just the legality check. Or do you generate only legal moves?
>>
>>>I'm not completely sure I understand what you're asking.
>>>The if(in_check(OTHERSIDE(whoseTurn))) test is checking
>>>for an illegal position (ie if the move leaves the side
>>>moving in check).
>>
>>Actually, this is how I understood it first, but then I got unsure ...
>>
>>I assume you extend checking moves normally in search. So what can happen?
>>Assume you have depth 5. Now you try all the legal moves. You check the hash for
>>a cutoff (draft 4 is enough). But what if one move is a checking move? In a
>>normal search, you will probably extend one ply, and then search again for the
>>other side with depth 5 again. So, in the "normal" search, you also need draft 5
>>or better for a cutoff from the hash.
>>
>>So, it looks to me, that all search extensions are ignored by this approach.
>>Especially, I would think, that very often the ETC is successful in typical game
>>situations where the normal search wouldn't be. Earlier you quite likely will
>>have searched the same line in the above example with depth 4. And stored it
>>with draft 4 in the HT. You made the checking move. And searched again with
>>depth 4, and stored with depth 4. No, the next time you visit the position, the
>>first HT probe will fail to yield a cutoff (5 needed, 4 available), in the probe
>>code above, you will have enough draft (4 is enough). But I think, this works
>>against the idea of search extension. This is also the reason, why I did not
>>experiment with ETC yet. To take search extensions into account will almost
>>yield in a full fledged search loop.
>>
>>I must admit, that I had some problems to express myself clearly here :-(
>>If it is still too confusing, please complain, and I will try again.
>>
>>Regards,
>>Dieter
>
>Actually, after I pressed Submit, I understood what you were asking :-)
>
>When I enter a node, I do this (ignoring some stuff that's not relevant):
>
>1. Calculate draft, which is (depth-ply).
>
>2. Probe the hash table, looking for the current position. If I find
> it with appropriate scores and drafts etc, I return. Note that I'm
> checking *before* applying extensions for this node.
>
>3. Work out what extensions are required at this position (eg check, recapture
> etc).
>
>4. Check to see if (given the extensions applied) I should enter qsearch.
>
>5. Try a null move.
>
>6. Try the hash move, if one was found in step 2.
>
>7. Generate the moves
>
>8. Do the ETTC loop shown above.
>
>9. Enter the main loop. Here, I make moves, then recursively
> call alphabeta() with ply+1 and (depth+extensionsAtCurrentPly).
>
>
>I think I do have an error, as you say. What I should be doing is
>incorporating the extension for the current node in the test for
>"sufficient draft" in my ETTC loop. I have a feeling that other
>people do the extensions in a different place (after each make_move
>in the main loop?) and for them this would look different again.
>
>Thanks a lot for spotting this, Dieter.
>
>My apologies for the rambling nature of this message; as much as
>anything, I'm "thinking aloud" to help myself understand what I
>am doing wrong.
>
>
>Andrew
I think you don't have any error, as long as you store the hash stuff (after
the search is completed for that node) with draft=depth_before_extensions. This
was, your probes and your search is consistent. Right?
José C.
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.