Author: Frank Phillips
Date: 01:22:50 08/22/04
Go up one level in this thread
On August 21, 2004 at 23:26:51, Robert Hyatt wrote: >On August 21, 2004 at 19:51:22, Stuart Cracraft wrote: > >>On August 21, 2004 at 17:23:30, Robert Hyatt wrote: >> >>>On August 21, 2004 at 13:20:11, Stuart Cracraft wrote: >>> >>>>All, >>>> >>>>SEE increases my nominal iteration depth by 0.42 pawns >>>>given the same amount of time as a non-SEE search, all else >>>> >>>>SEE decreases my max quiescence depth reached (with a check handoff >>>>to main search) by a little under 8 ply for the same problem set. >>>> >>>>These are the 300 positions from Win-at-Chess run at 1 second per >>>>problem on an old, slow, notebook. I do not have comparative data >>>>due to the subjectivity involved of chess games and the "feel of SEE". >>>> >>>>Legend: >>>>Ave Iterative Depth/Average Max Search depth >>>>% solved >>>>Total solved / Total in test >>>>Total time taken (300 seconds allowed) >>>>Total Nodes searched >>>>Average positions searched per problem / >>>>Average time (rounded) per problem / >>>>Average nodes per second per problem >>>>0/0/Check Extensions from Quiescence back to Main Search/0/0 >>>> >>>>Without SEE >>>> >>>>**** 6.68/27.18 68% 204/300 269.05 54264704 180882/1/201692 0/0/3361112/0/0/0 >>>> >>>>With SEE >>>> >>>>**** 7.10/19.01 64% 193/300 267.44 46135172 153784/1/172505 0/0/1154026/0/0/0 >>>> >>>>Total problem solution rate drops 5.4% and nodes searched drops 14.98% >>>> >>>>(The SEE being used above was tried as (1) see < 0 then don't search >>>>a capture move in quiescence and (2) see < delta where delta is calculated >>>>with its margin off alpha as the maximum positional score so far in the >>>>search for the side on move. The above results are the combination of both and >>>>if only using the #2, assuming for example my SEE is not a great SEE, >>>>the result is only slightly changed.) >>>> >>>>My question is, why should SEE reduce the tactical result so drastically >>>>and is it safe to do so given the depth and nodes results are favorable? >>>> >>>>Thanks ahead, >>>> >>>>Stuart >>> >>> >>>SEE should _help_ in tactics, not hurt. If it is hurting, there is something >>>wrong somewhere... >> >>That is probably true unless you are doing extremely short searches in >>very short periods of time on a slow box. > >SEE, when done correctly, is very accurate. It really will not hurt tactical >accuracy enough to measure, but it will speed you up enough to spot tactics you >would otherwise overlook due to a lack of time. Overall your tactical score >must go up when you have it working correctly, as it will speed the search about >2x overall... > >> >>I guess people's admonishing me to go to longer searches and analyzing >>with games is understandable. Most people have said this. >> >>I can't do this because my research, in autotuning, requires short, >>fast searches on the order of <1 second. > >Time doesn't matter. If you use SEE to limit the q-search, it should make you >2x faster. That will improve your tactical scores > From some extremely cursory testing I am so sure it is so clear cut. Certainly the number of nodes to reach a given depth reduces dramatically, but it sometimes takes a ply extra or more to find solutions to test problems – and therefore evens out to some extent. This could be because such problems are inherently anti good move ordering ie throw stuff away now for later benefit. But the SEE obviously misses pins (mine does anyway) and so the predicted capture sequence is often false, even deep down the tree. Whether this matters much, because qsearch in inherently inaccurate, is moot at the moment for me. As always, a lot depends on the rest of your program...... And simple tactical tests suites (like WAC) seem to have limted value for predicting performance in real games, in my view. Logically, I am inclined to believe that it is better spend your limited time in the main (less error prone) search, of coures. > > >> >>So I can't use the benefit of SEE or some other advances that require >>longer searches. I see them with longer searches, but I can't use them. >>It is all #ifdefed out > > >For reference, Crafty gets 293/300 on WAC at 1 second per move on a 1-cpu 2.4ghz >opteron run: > > > > >total positions searched.......... 300 >number right...................... 293 >number wrong...................... 7 >percentage right.................. 97 >percentage wrong.................. 2 >total nodes searched.............. 661280521 >average search depth.............. 9.8 >nodes per second.................. 2729068 > > >Or a full-blown 4 cpu run at 1 sec/move gives this: > >total positions searched.......... 300 >number right...................... 298 >number wrong...................... 2 >percentage right.................. 99 > > > >> >>In time, given the inexorable progress of hardware, they'll be #ifdefed >>back in. >> >>I am grateful for all the input from yourself and everybody because it >>has greatly shortened the timeframe for a halfway decent base on which >>to build. Bbelieve me, I have enough trouble with my own code that I don't want >>to retrofit other code. I am not a crack programmer and have no idea where >>people get their ideas. >> >>Hope this clarifies my resistance and the reasoning behind it. Still looking >>for short, sharp enhancements for small trees but the time is approaching to >>change the course of this work and get to the real fun and out of the "Quagmire >>of Featuredom". >> >>Stuart
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.