Author: Robert Hyatt
Date: 21:31:51 09/10/99
Go up one level in this thread
On September 10, 1999 at 22:40:36, Bas Hamstra wrote: >Disclaimer: I have a simple and rather "young" program. But I think the "core" >behaves consistent. > >I use no pvs but ab with aspiration window at the root. With that I can not >confirm your results. I happened to use exactly the scheme in the code that was >posted here. I tried 3 positions: 2 wac (one wac141, the other forgot) and the >startposition. In all positions I get the fewest nodes playing *any* hashove >before the captures. Think about what you just said. It implies that something inefficient is going on inside your search, because in fail-low positions, you really are trying "any move" before trying a capture. If that doesn't kill your search, the next question is, how many times to you really use such a move? You might simply be lucky enough that it isn't happening that much. I don't hash q-search, which means my table doesn't have a serious overwrite problem unless I search for tens of minutes. Maybe that is why I saw worse results, because for my tests, the hash table was nowhere near full, as I always run with hash=384M. > >After reading this this discussion I tried skipping the hashmove in case of >UPPERBOUND. It got more nodes at all depths. I tried using only EXACT moves, and >got even more nodes. > Using EXACT is bad. In PVS it is fatal, because only a few dozen positions get stored as EXACT. The rest are either UPPER or LOWER. If LOWER, you have a perfectly good move that just refuted the opponent's last move, and you ought to try it whenever possible. For UPPER, I don't see a way to get anything but a fairly random move... Unless your eval doesn't have significant positional scores (mine is typically +/- 2.00 in the middlegame) or if your eval is still very simple and isn't differentiating between positions very well yet... >Same results with and without nullmove. My captures (in search and qsearch) are >ordered basically 100% SEE. I mean even when Attacker < Defender the SEE value >is determined (will optimize later, if necessary). > >Are there any others using naked alphabeta in stead of pvs who can do this >little test? > >Regards, >Bas Hamstra. > PVS is a winner over normal alpha/beta, by at least 10%, and often much more. It is worth trying. > > > > > > > > > > > > > > > > > > >On September 10, 1999 at 14:01:42, Robert Hyatt wrote: > >>As promised, here is some data. The 'old' column is the standard >>released version of crafty 16.18. Which on positions where all moves >>have a score <= alpha, _no_ move is stored in the hash table, although >>the bound is stored for later use. 'new' uses the simple trick mentioned >>by Ed, namely setting best to -inf, then raising it every time a score >>comes back that is higher, and also remembering the move that went with >>that score. That move is now stored in the hash table when this node >>has been finished. >> >>I ran 3 kopec positions, three that aren't tactically motivated, and >>two that are (4/5) plus wac 230 which is a deep tactical shot that >>combines both types of themes... Until it finds the deep shot, it >>appears to be a pure positional problem, then suddenly at depth=16 >>it finds that Rxb4 fails high along a precise tactical line. So three >>normal type positions, three tactical positions. >> >>pos old new >> 1 4.897M 5.018M (kopec 2, 11 plies) >> 2 10.713M 13.563M (kopec 3, 11 plies) >> 3 14.739M 15.175M (kopec 4, 11 plies) >> 4 25.478M 30.032M (kopec 5, 11 plies) >> 5 9.272M 9.083M (kopec 22, 12 plies) >> 6 39.971M 41.749M (wac 230, 16 plies) >> >> >>The results seem quite clear to me. Trying to figure out a 'best >>move' at fail-low nodes doesn't work. Using such moves before the >>capture search blows the tree up. Sometimes only a little, other >>times drastically. >> >>As I said, I don't see _any_ way to reliably find the best move >>at a fail low position. you might think this trick works, but >>it doesn't. This is just a fact of life with alpha/beta. The search >>returns _bounds_ that can't be compared to each other to say that >>"just because this move has a bound <= 200, while this move has a bound >><=250, clearly the bound <= 250 move is better. Alpha/Beta just doesn't >>work that way. Minimax will. But trying this made the trees larger >>in every case but 1, at least for me. I'll be happy to test any other >>positions anyone suggests, of course.
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.