Author: Tord Romstad
Date: 09:56:39 03/04/04
Go up one level in this thread
On March 04, 2004 at 10:33:12, Fabien Letouzey wrote:
>
>Hello Tord,
Hello, Fabien!
>On March 04, 2004 at 09:12:38, Tord Romstad wrote:
>
>>On March 03, 2004 at 09:31:22, Matthias Gemuh wrote:
>
>>>xx depth without extensions
>>>yy includes extensions in main search, not quiescence
>
>>I don't think the standard specifies what the "seldepth" is supposed to mean,
>>and I don't think xx and yy have the above meaning in all UCI engines.
>
>My post was indeed about holes in the UCI document and other non-standard
>features, hence the title "in practice".
>I think UCI engine authors can agree about "common non-standard" features :)
>
>>In Gothmog, I use them in approximately the way you describe. xx is the
>>iteration number (which in my engine is not quite the same as "depth
>>without extensions", because my search is not even close to fixed-depth),
>>while yy is the longest line searched in the main search.
>
>Do you use a probability-based "depth decrement" if I may ask?
>One that estimates a probability distribution of moves at every node, and
>decreases the "remaining depth" by the log or something similar?
>This is anyway only a generalisation of SEX/fractional-ply algorithms.
>It also includes singular extensions as a special case.
>
>Sounds really slow, but I think worth a try.
>One could switch to normal ply-counting near the leaves anyway.
>
>You can answer by just yes or no :)
It is interesting, but not very close to what I am doing at the moment. At
the beginning of a new iteration, I initialize the search depth to 12 times
the iteration number. At all nodes in the main search, for each move I
calculate what I call the 'cost' of a move. This cost is subtracted from the
remaining depth in the recursive call to search(). In pseudo code, it looks
roughly like this:
for(m=pick_move(); m!=NULL; m=pick_move()) {
make_move(m);
cost = find_cost(m);
value = -search(-gamma, depth-cost);
...
}
The cost of a move can range between 0 and 36. Promising checks are "free",
i.e. they have a cost of 0. Mate threats, dangerous attacking moves,
single-check-evasions, advanced passed pawn pushes and similar moves have
a low cost (usually between 0 and 8). "Neutral" moves are given a cost
between 16 and 8. Moves which look bad or pointless have a really high
cost. Moves with a cost bigger than 16 are re-searched with a lower cost
if they fail high.
Essentially, this is of course nothing more than the usual ideas of
fractional extensions and reductions (except that in my search, an
unusually big fraction of the moves are extended or reduced). Extensions
correspond to low-cost moves, and reductions to high-cost moves. I just
consider it cleaner and more elegant to unify the two concepts to the
single concept of cost.
I have considered using a more flexible system where I compute the cost
of a *path* instead of the cost of *moves*. Instead of checking whether
the remaining depth is less than 0 before deciding whether to call
qsearch(), I would check whether the cost of the path leading to the
current node is bigger than the current iteration number. This idea
looks interesting, but I'm afraid the resulting search inconsistencies
would be too painful.
>About "yy", can you confirm that you never include quiescence plies in it?
Yes.
>I don't really understand why stopping there, quiescence search is also a
>selective search ...
Simply because the longest line in the main search is a more useful and
interesting number to me. Other engine developers no doubt think
differently.
>By the way, I believe Gothmog has a *very* bright future; good luck :)
Thanks. :-)
I am not so optimistic about the future myself -- most of my recent
attempts at improvements have been very unsucessful. It also looks
like I will not have much time to work on my engine the rest of this
year, but I still hope I will be able to release a few new and stronger
versions.
Tord
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.