Author: Vasik Rajlich
Date: 17:04:33 03/19/04
Go up one level in this thread
On March 19, 2004 at 06:40:12, Tord Romstad wrote: >On March 18, 2004 at 18:15:52, Vasik Rajlich wrote: > >>On March 18, 2004 at 17:09:47, Tord Romstad wrote: >> >>>On March 18, 2004 at 16:43:02, Mridul Muralidharan wrote: >>> >>>>Hi Tord , >>> >>>Hi Mridul, >>> >>>Are you sure you get enough sleep? :-) >>> >> >>I'm pretty sure he gets enough (sleep+caffeine) :-) > >I hope so. :-) > >>>But my search is already extremely path-dependent anyway. In principle I >>>don't like this, but the way my search currently works I wouldn't be able >>>to get rid of the path dependencies without making my search trees many >>>times bigger. >> >>Actually, why couldn't all of your path-dependent extensions be converted to >>non-path-dependent extensions? Ie. if you are extending something because >>something happened earlier in the variation, why cannot it be formulated in such >>a way that you are extending based on something which is currently true about >>the position. > >I have found that doing aggressive forward pruning or reductions is dangerous >if I don't consider the path leading to the position. Perhaps you remember >from the description of my search that I never reduce a move if there >was an extension in one of the last two plies before the move. I've found >that removing this restriction causes too many tactical mistakes. > >Note that path-dependency is actually very common in chess engines. All >engines which use the recapture extension or which do checks in the >first ply of qsearch only if the preceding move was a null move suffer >from path dependencies. Most authors seem not to worry much about it. > Recapture extensions could be reformulated (as far as I can see) to be path-independent. One such formulation would be any capture which restores the material balance. Another formulation would be any capture which is also singular, since usually in a capture-recapture sequence the capture is voluntary while the recapture is forced. I was wondering if there's any mileage from a distinction between "fundamentally position-dependent" and "fundamentally path-dependent" features. In the latter would be included things like noting that one side has just played one forced move after another since the root, so the current position is actually vitally critical for him. This is an attempt to distinguish between low-depth positions in which you are extending something so that you can play a sligthly better positional move somewhere along the line, and low-depth positions in which you are extending something which still has a big effect on the root evaluation. I was also thinking that this would be especially important at fast time controls. It's quite ok in blitz for the program to make all sorts of "oversights" at the leaves, as long as the result is only some positional inaccuracy. The one thing you can't afford to do at a fast time control is make some oversight anywhere in the tree which propagates back up to cause a real blunder at the root. Anyway, I'm not sure I'm explaining this well. I'll eventually return to this and let you know if anything comes of it ... >>I have had in my mind an idea that I call "committment". In each position >>reached by the search, both sides have a "committment" to that position. For >>example, imagine that you start in some position and white plays four >>consecutive forcing moves. Black is highly committed, if this position is >>losing, then the root move is winning for white. White, on the other hand, may >>not be especially committed, since any of his forcing moves had alternatives. >> >>My idea for measuring this was by using the results of the null-move searches. >>(For this you need very good fail-soft.) When a null-move search fails badly, >>the side playing the null move retains most of his previous committment. When a >>null-move search barely fails, the committment value goes down. >> >>You could do a number of things with this. For example, checks would be extended >>more when the other side is more committed, etc ... > >I do something like this, but it is based on the static eval rather than >search. For instance, as you know, I am extending certain attacking moves. >This is not done if the side to move has a clear advantage. On the other >hand, if the side to move has a material disadvantage, attacking moves are >extended more than usual. > >My king attack extensions are biggest in unbalanced positions where the >side to move is behind in material, but the other side has very bad king >safety. It is extremely hard to write a king safety eval which is >sufficiently accurate to decide whether the attacking chances are sufficient >to compensate for the material. Therefore it is important to search >checks and moves that increases the pressure on the enemy king especially >deeply in such positions. > Yes, true. This could also apply to passed pawns - the point is that the uncertainty on certain evaluation terms is higher in one direction than the other. In fact, I've set up my evaluation function to return uncertainties on its scores, although currently this is disabled. (It's all done with macros so that it's not costing anything ...) Vas >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.