Author: Vincent Diepeveen
Date: 11:31:01 12/12/00
Go up one level in this thread
On December 09, 2000 at 09:45:45, Robert Hyatt wrote: >On December 09, 2000 at 05:56:25, Georg v. Zimmermann wrote: > >>>> >>>>But this wont happen if your margin is large enough. As large as your largest >>>>position scores. As explained by Ernst. Very simple. And accurate. >>> >>> >>>Yes... but if the margin is "big enough" then you don't have futility pruning, >>>either. That is the problem. And if you eliminate _one_ node from the tree >>>search, you stand the chance of perturbing the score that eventually backs up >>>to the root of the tree, due to the hash table. >>> >>>The problem with "big enough" is that for some programs, "big enough" might be >>>a pawn or two. For other programs it might be way more than a queen. Such a >>>window effectively disables futility pruning. For those that want to produce >>>very large positional scores. >> >>What I am doing is to set value = fmax = eval(); instead of materialeval(). That >>way your margin can be the maximum eval change in 1ply only. This obviously only >>works if your eval() is very fast. If not, you can try to write another >>fasteval() function which only uses those eval parts than can get very big, king >>safety for example. I got good results with that. >> >>Regards, >>Georg v. Zimmermann > > >The problem is that an eval can change a _lot_ in one ply, for some programs. >IE mine could change by at least a queen for the right kind of capture. Or >the right kind of pawn move. Hello, exactly the fasteval is what i put in months of effort. I put in about 1/10 of my evaluation inside it, also the king safety was for the biggest part put into this evaluation. I measured that around 99% of all evaluations done after using QuickEval() as it's called in my prog that this was within 3 pawns positional score. So then i started playing some games with this version and it took some months to realize, but the version without the fasteval implementation simply played better and was tactical scoring MORE on testsets despite that the version using the fasteval was producing a huge speedup. Also using 3 pawns is quite huge. still. a big problem is that you need to reduce that from the score. evaluation_approximation = quickeval(); Now for the beta side (i skip alfa as that goes identical) if( score-3pawns >= beta ) return(score-3pawns); returning the score is simply too buggy anyway. However returning score-3pawns is gonna use HELL of a lot more nodes. At least in my program. Practical despite the program searching several times faster as the version without it simply needed more time to get to big search depths (so levels like 3 minutes a move or more). That removed all fun of course. Also in fact this fasteval simply DICTATES that the huge eval can *never* deliver more as 3 pawns. This is simply not true. There are many important cases where scores are way higher. We're not talking about 3 patterns here but about the MAJORITY of patterns. That's possible hundreds of patterns that apply to a single position. If those are by accident favouring one side then the advantage can go up to many pawns easily. Despite that it only happens in 1% of the cases that it goes over 3 pawns (so more as 3 pawns COMPENSATION, if it only makes the score higher i don't care of course too much basically). So it positionally also hurts bigtime as it simply solves many positions at bigger search depths as the normal version does. Especially solving obvious tactical tricks for mankind you simply can't afford to limit your positional evaluation. Yet the biggest problem is the bigger branching factor which you get because of returning score-3pawns instead of a more accurate score. Most likely you return score+xpawns instead of score-xpawns of course, so your cutoffs are always very near to beta. Not helping move ordering much!
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.