Author: martin fierz
Date: 02:28:06 03/19/04
Go up one level in this thread
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. 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. >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? >> 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. >Yeah, every programmer with a <1 month old engine tries a few super-extension >strategies. Then reality sets in :-) i never did this :-) - i have a set of extensions which either kick in or not, and if one of them kicks in i get a 1-ply extension. then again, i was programming checkers for years before, so i knew about the dangers of allowing more than 1 ply per ply. cheers martin
This page took 0.01 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.