Author: Robert Hyatt
Date: 08:37:06 08/17/04
Go up one level in this thread
On August 17, 2004 at 10:16:09, Stuart Cracraft wrote: >On August 16, 2004 at 15:31:42, Robert Hyatt wrote: > >>On August 16, 2004 at 15:23:58, Stuart Cracraft wrote: >> >>>I completed some testing on two recently added features >>>that probably will become permanent additions to this >>>program at all time levels. My conditions for these kinds >>>of additions are: >>> >>> o reduces search tree without damaging test suite results >>> o average ply doesn't drop drastically, preferably increases somewhat >>> o plays reasonable chess and can continue to trounce me >>> >>>The first feature is SEE and was motivated by readings but mainly >>>Bob Hyatt's effective, repeated harping. Fortunately I did >>>not have to write it and it was very kindly donated to the program >>>which makes it even easier. :-) >>> >>>The research explored 3 uses of SEE: >>> >>> 1) use SEE to score each capture, as the move is generated, >>> and then for later sorting, prior to the normal quiescence and >>> main search uses of the movelist and its scores >>> >>> 2) use SEE for delta pruning / futility cutoff with a MARGIN >>> of 1.5 pawns >>> >>> 3) use SEE to Draconianly cutoff any quiescence capture where SEE < 0. >>> (the so-called "delta prune" or "futility cutoff in quiescence". >>> >>>#1 showed its disadvantages quickly. Generating a SEE for every >>>move instead of or in addition to MVV/LVA was costly. Using #1 >>>dropped test results negatively. Test results include tree sizes, >>>average ply, etc. This program does not generate and search individual >>>moves on the fly and then generate the next move, etc. All captures >>>or all moves, all at once. >>> >>>#2 had a bug initially with MARGIN being set to only 1/5th of a pawn >>>or just to the maximum positional score of the side on move (usually >>>less than a quarter of a pawn.) When the MARGIN was upped to 1.5 pawns >>>the trees were improved and the tree results were better without hurting >>>test scores much. The model for this version was GNU 5 and I have >>>not researched the MARGIN value as much as I would like. I would like >>>to know what people do. How about 1.5x, 2x, 3x the max positional score? >>>Any other hard or adaptive settings worth exploring? How about depth >>>or game-phase auto-variants? >> >>Why more than 1.0? What possible error can 1.0 introduce since you can't >>produce a positional score larger than that, and since the material value is >>static, making it larger makes no sense... > >No reason other than I noticed a lot more cutoffs with higher MARGIN >My maximum positional is about 1/3 to 1/2 a millipawn... You have to have a bug then. IE if your margin is higher than the largest positional score, then making the margin _larger_ can not have any affect on the tree size whatsoever. If a score is <= X, then I can guarantee you it must be less than X+N where N is a positive number. :) >> >> >>> >>>#3 Also helped and showed good tree results without horribly affecting >>>test score. >>> >>>So I kept #2 and #3 and discarded #1. Many people have objected but >>>all I have to say is that Schaeffer is probably right when he writes that >>>all one needs for move ordering is probably hashing and history heuristic >>>besides the hash move and pv's first, etc. All I use in addition to those >>>is MVV/LVA, a centrality table, and a castle bonus to create the score. >>>Every other attempt to improve here has failed. >> >>Schaeffer really didn't say exactly that. Getting good captures first is >>_critical_ to tree size, because captures more often refute moves than any other >>single kind of move... > >I experimented with SEE. Putting SEE into all move ordering (move >generator for captures only in quiescence) and move generator for >all moves in main search. This slowed down performance and impacted >solution rates. I verified that the see<0 captures were getting scores that >drove them down (much) further on the list. I suppose they should not >be the very last moves searched but with negative see() scores there's >not a lot of choice for me. So perhaps that is the reason. They should >be lower but not all the way at the bottom. This isn't the way to do things. Search captures with see > 0, in order of SEE, except when you can safely use mvv/lva to avoid SEE overhead (ie if you can play BxQ then you can safely assume +6 based on MVV/LVA without doing a SEE since that capture definitely wins material). Then search captures with SEE = 0, then the killer and history moves (I do 2 killers, 4 history moves) and then I search the rest of the list in order, which has the losing captures (SEE < 0) first since I generated those first. Of course hash move always comes first... However, your test methodology is _still_ flawed. If searching losing captures early makes you faster, then you are searching positions where sacrifices are the winning moves. That is _not_ the case in real games, in 99+% of the positions searched. Don't base decisions on WAC or ECM. I wouldn't evaluate a programmer based on his ability to perform CPR. That is not going to happen very often and most of the time he will be doing something _different_.
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.