Author: Tord Romstad
Date: 03:28:03 03/19/04
Go up one level in this thread
On March 19, 2004 at 05:28:06, martin fierz wrote: >On March 18, 2004 at 17:42:56, Vasik Rajlich wrote: > >oh, this was an interesting thread to follow :-) >i'll add my 2 cents to it, although of course muse isn't quite as strong the >other engines you were discussing, meaning my ideas are worth less... > >>>>I use a hybrid approach. Among many other things, my evaluation function >>>>tries to measure the tactical complexity of the position, by considering >>>>the number and values of hanging, pinned or overloaded pieces, and looking >>>>for possible forks. If the position is sufficiently simple, I replace >>>>the q-search with a SEE. If it is more complicated, I do a search. >>>>Depending on the position, I search only captures and promotions, or >>>>also promising checks, forks, and moves which bring attacked pieces to safe >>>>squares. > >i do "good checks" at the first N plies of QS, if a simplified king-safety >measure is above a certain value (more or less # of pieces attacking the king - ># of flight squares for the king). N=1 at the moment, but it's actually a >parameter in my program. >good checks are defined as checks on squares where the checking piece cannot be >captured or only be captured by the opponent king. >from what i read, you guys are doing more sophisticated stuff for detecting good >checks and deciding whether to check or not. In my case, it's not a lot more sophisticated. The king safety of the opponent's king is the most important factor in my case, too. I also consider the value of the static eval. If the side to move is clearly winning, I don't search any checks at all (this is one of several reasons why Gothmog often finds the right move quickly in test positions, but needs a very long time to see that the move leads to a forced mate). Some path-dependent information is also used. Checks are more likely to be important if there were many checks or attacking moves in the path leading to the position. Unlike you, I search checks at all levels in the qsearch, not only in the first N plies. In order to prevent explosions, I count the number of qseach nodes visited since the engine left the main search. When this number exceeds a certain threshold, I stop searching checks. I use the SEE to cull checks which appear to lose material. While writing this posting, I suddenly became aware of something I should have thought about a long time ago: I shouldn't really do this for discovered checks. >i suspect that my limit of N=1 is >due to the fact that i do too many/the wrong checks, i.e. i should allow checks >with SEE >= 0 instead of what i wrote above. unfortunately my SEE is not >x-ray-aware, so i'm a bit afraid of using it for such purposes. then again, i'm >using it to prune qsearch too ;-) >i should really fix up my SEE to include x-rays, but it will slow me down *even* >further - i believe i have about the only engine slower than gothmog :-) > >my problem here is that my SEE uses attack tables that i compute at every node i >visit (i wish i knew how to just update them, but i don't, so i compute them >every node, very slow...). i decided i had to make my SEE use them so that it >would somehow justify the expense of computing those attack tables. >anyway, i'd have to add x-rays to my attack tables to improve my SEE. I also use attack tables for SEE computations. My attack tables contain some x-ray information, but it is not sufficient to always give a accurate result. Instead of trying to patch the hole, I have tried to make my engine able to guess when it is safe to trust the simple SEE. When it isn't safe, a slower and more complicated SEE which does not use the attack tables is called. >>Yes, I remember this. Thinking about it again, this must be the correct >>approach. However, I'd prefer to be making a decision between SEE and a >>bare-bones q-search. Forks in q-search seem really expensive, especially if >>you're going to try to handle them right and consider all the various defensive >>resources, etc. I'm happy to leave forks to the main search. > >i don't do forks and i don't think i will - seems very expensive, besides, you >need to keep detecting them: say you make a pawn fork now between two opponent >pieces in your QS, then what? your next ply of QS will not see any fork and >evaluate the position - so your eval has to decide how bad that fork is? or do >you really want to look at all moves after the fork? >or were you just talking about checking forks? Yes, only checking forks. Sorry for not being more clear. >>> I did not understand the last part - >>>This could mean , you use either : >>>1) Allow multiple ply extension per position. >>>OR >>>2) Use fractional extensions. > >i don't use fractional extensions. my feeling is that fractional extensions are >good for the lazy. a human either extends or doesn't. of course, the human has a >better algorithm for deciding when to extend. but still: i'd say most programs >today have very stupid extensions, for example the check extension. so many >checks/positions are ridiculous, if you look at them (for example all kinds of >captures around a safe king, or positions where somebody already is a queen up >etc). but they get extended. so in order to make that work better, people turned >to fractional extensions, basically saying that instead of really deciding >whether to extend a line one ply or not, they extend a fractional amount so as >not to blow up their search and in the hope that if you do 2 interesting moves >after each other, you get rewarded by an extension. >i believe that this is the wrong approach, and that you should rather focus on a >better decision on when to extend and when not. of course, i'm not really doing >this very well myself at the moment :-) but it's something i'd like to work on >some time. I am not sure I agree with your views here. If the current path contains two moves which are *almost* interesting enough that you want to extend them, I think it makes a lot of sense to extend by one ply. 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.