Author: Vasik Rajlich
Date: 02:24:19 12/10/05
Go up one level in this thread
On December 09, 2005 at 15:24:03, Uri Blass wrote: >On December 09, 2005 at 14:52:41, Vasik Rajlich wrote: > >>On December 09, 2005 at 11:50:42, William Penn wrote: >> >>>Rybka's analysis is fairly short to begin with, compared to most other engines. >>>It reaches its maximum after a few seconds, then it decreases at longer times. >>>For example here's an analysis of a position in infinite mode using the Shredder >>>Classic GUI. After 3 hours it is already showing a decrease of move information, >>>which decreases even further after 10 hours. The specific position doesn't >>>matter. I see this same pattern when analyzing any position for a long time. >>> >>>Engine: Rybka 1.0 Beta 32-bit (704 MB) by Vasik Rajlich >>>12.01 0:03 +1.35 32.h4 g4 33.h5 Qf8 34.Qe2 Nb4 35.Rh4 Qe8 36.Ne3 (300.979) >>>87 >>>13.01 0:06 +1.37 32.h4 g4 33.h5 Qf8 34.Qe2 Nb4 35.Rh4 Qe8 36.Ne3 Qe6 >>>(552.306) 90 >>>14.01 0:15 +1.36 32.h4 g4 33.h5 Qf8 34.Qe2 Nb4 35.h6 Qf7 36.Qd2 Qe6 >>>(1.362.839) 90 >>>15.01 2:02 +1.34 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Ne6 36.Rxg5 fxg5 >>>(9.586.923) 80 >>>16.01 3:01 +1.31 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Ne6 36.Rxg5 fxg5 >>>(14.741.441) 83 >>>17.01 5:30 +1.27 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Qg8 36.Rh4 Ne6 >>>(27.355.485) 84 >>>18.01 10:34 +1.19 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Qg8 36.Rh4 Rg6 >>>(52.200.357) 84 >>>19.01 18:28 +1.25 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Qg8 36.Rh4 Rg6 >>>(90.818.525) 83 >>>20.01 42:12 +1.13 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Qg8 36.Rah1 Ne6 >>>(200.052.005) 80 >>>21.01 92:04 +1.18 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 35.Rh5 Qg8 36.Rah1 Ne6 >>>(427.366.814) 79 >>>22.01 174:11 +1.14 32.h4 Qf8 33.hxg5 Rxg5 34.Qf3 Nc7 (789.072.165) 77 >>>23.01 634:58 +1.24 32.h4 Qf8 33.hxg5 (2.860.235.585) 76 >>> >>>WP >> >>This is intentional and can _very_ easily be fixed. Please send me an email if >>you have a strong opinion about the matter. >> >>In my opinion, other engines talk too much. The ends of the PVs tend to be >>pretty silly. >> >>Vas > >I think that they do not talk enough. > >I think that it is productive to have an option to see more for correspondence >games like hash moves that you already remember at small depth for every move. > >I will be happy if rybka can write them to a text file. >The point is that one problem in analysis is that a program may suggest line >1.xx yy after many hours of search and you may need hours to see the reason that >it rejected 1.xx zz because 1.xx zz is not the pv line > >If the program can print to a text file the first move that it tries in the >first 3 plies then it may be productive. > >Example in the opening position suppose the pv is 1.e4 e5 2.Nf3 Nf6 3,Nxe5 > >I would like to see in text file something like >1)the following 19 lines for depth 2 >1.d4 d5 >1.c4 e5 >... >2)the following 19 lines for depth 3 >1.e4 a6 2.d4 >1.e4 a5 2.d4 >... > >If I do not see it then I may need a long analysis to understand why the program >rejected 1.d4 for white or may need a long time to understand why the program >rejected 1.e4 a6 for black > >Note that it may be productive also to have lines at bigger depth for thinking >lines that the computer considered for a long time and if the program considered >1.d4 d5 2.Nf3 for a long time then I would like to see the hash move after these >moves in order to understand why it rejected 1.d4 d5 2.Nf3 for white. > >Uri Uri, this is a response also to your email, as well as a number of other emails I got about this. In the short term, an engine can only display a PV, and this PV can only be slightly shorter or slightly longer. This doesn't give the engine programmer much leeway, and I think we all agree that a long single search isn't a very useful use of many hours of computer time. Anyway I have now changed the behavior so that the PVs at least continue getting longer as more time is spent. In the long term, we should be able to instruct a chess package to spend several hours analyzing a position and giving us a full report. There are already some implementations of this, mostly at the GUI level, which is where they belong. In principle, these features should be better. Some ideas in this direction: 1) The GUI makes a package report about the position - deep analysis of a number of lines, as well as a number of "shootout" games together with statistics. Everything should be as automated as possible. 2) The GUI allows the user to specify the type of analysis he wants - more positional (ie. just a few moves), or a wilder (fuller) tactical search with more variations. 3) What I call "key variations". A PV is the variation which gives you the root score. A KV is a variation which best explains the difference between the analysis of an engine at two iterations, and captures tactical themes much better. I have a formal definition for this, and KVs may soon be part of some UCI extensions which are under consideration. 4) The GUI allows the user to correct the engine on some points. For example, you want a root position analyzed deeply, but your engine thinks that some totally blocked position is winning and can't get past this, the user should be able to tell the engine to behave as if this weren't true. 5) The GUI allows the user to specially configure the engine for the position. For example, the engine could be instructed to value space less for this analysis. This special configuration should be part of the report. So don't worry, there will be better tools to help you with this. Vas
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.