Author: Vasik Rajlich
Date: 04:11:58 03/05/04
Go up one level in this thread
On March 04, 2004 at 12:56:39, Tord Romstad wrote:
>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.
>
Hi Tord,
if you don't mind sharing a few secrets, I have a few more questions:
1) How do you determine if a move is pointless? Is it purely static positional
eval? Ie. Rca1, moving rook from open c-file, to closed a-file, etc. (Of course
assuming no tactical reason to reduce the cost.)
2) What is your cost for tactical moves which appear to lose material. For
example, Bxg7 giving up a bishop to expose the king?
3) Do you combine the above with recursive null-move? If yes, do you have
problems with the huge depth reduction of pointless moves followed by a null
move?
4) How does/would your engine score against the exact same engine, with all but
the most basic selectivity taken out?
4a) Another interesting test: Your engine vs the same engine, but with all move
costs > 12 (or maybe 16) changed to 12. (Ie all extensions remain, all
reductions taken out)
Ideally tests #4 & #4a should give some minimal search time, let's say enough to
search 10-20 million nodes/move. I don't doubt that the selective engine is
faster with simple tactics.
It seems to me that it is more promising to extend (ie costs <12, while leaving
the bulk of the costs at 12) than reduce. It's also important to watch for the
tactical vs positional line. High costs for "bad positional moves" seems like
another way to emphasize tactics.
>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.
>
Interesting. As I understand it, this is to deal with the problem of deciding if
a positional move is pointless, for example a move which temporarily
de-centralizes a piece en route to a better square. I've thought about this a
bit. The problem is distinguishing between a variation in which a poor-looking
move turned out well because it was a fundamentally good re-positioning and a
variation in which a poor-looking move turned out well because in that line the
opponent made a mistake.
At this point I have very little confidence in distinguishing between good
positional moves and bad positional moves, other than the final search outcome.
>>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
Vas
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.