Author: Vasik Rajlich
Date: 17:08:39 03/19/04
Go up one level in this thread
On March 19, 2004 at 06:28:03, Tord Romstad wrote: >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. > BTW I am quite sure that Shredder is doing some sort of massive tactical static node analysis. There was a review of the newest engine on the chessbase web site, they claim that in many positions Shredder 8 goes an average of two plies deeper than Shredder 7! It does 3x fewer NPS than Fritz, and yet it does root-node preprocessing. All this per-node time is going somewhere, and it's not just eval ... So, I agree that slightly speculative things like x-rays in SEE are in the long-run a must, even though there will be many errors. >>>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. > I agree with Tord here. When I first started work on my eval, I couldn't imagine that I would want precision better than 1/16th of a pawn, and my first MTD (f) driver wasn't distinguishing anything closer than 1/8th of a pawn. (This version played in CCT6) Now I am at 1/32th for eval and 1/16th for the driver. It makes some sense to have this sort of "ridiculous precision" ... >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.