Author: Bas Hamstra
Date: 19:40:36 09/10/99
Go up one level in this thread
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. 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. 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. 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.