Author: Vasik Rajlich
Date: 10:04:12 12/10/05
Go up one level in this thread
On December 10, 2005 at 07:57:16, Uri Blass wrote: >On December 10, 2005 at 05:24:19, Vasik Rajlich wrote: > >>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. > >I do not agree here. > >many hours of computer time may be useful because the program may find a move >that it does not find in a different way or find a win that it does not find in >a different way(and knowing that there is a win in some position can be >productive for analysis). > >The point is that a similiar win may be available in a different line and if you >do not understand the reason that the program shows a winning score you may miss >the second win in analysis. > If you invest several hours of computer time, you should be able to get a good first move _and_ some additional analysis and information. > > > > Anyway I have now changed the >>behavior so that the PVs at least continue getting longer as more time is spent. > >Thanks >this is better(note that very long pv is not very impoertant but it is important >to have more than 3 plies on the pv because even the program may need a long >time to find the 4th move or the 5th move of the pv so you may be unable to use >short analysis to find it later). > >> >>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. > >I agree > > There are already some >>implementations of this, mostly at the GUI level, which is where they belong. In >>principle, these features should be better. > >Here I do not agree and I think that the engine should do it. >I think that better analysis should also lead to better move(otherwise it is not >better analysis) > In the really long term, yes, the engine should do it. For example, the engine can search classically and in addition also play a bunch of games, and use the results of the games to determine the best move. That will be really intelligent analysis. In the medium term, I think it's just a job for the GUI. >If you think that different algorithm is better for analysis then it should be >used also in playing games. A different algorithm may give on average a worse first move, but provide better alternative information for a human user. >> >>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. > >If automatic deep analysis of number of lines is productive(I believe that it >can be productive) then it should be used also in games and the program should >tell the user the intereting lines that it found. > >Having exact score for second best move at least in the first plies may be >productive also in games(for example it may allow the program to have better >time managament and play immediately when second best move lead to forced mate >against itself). > I think we're quite far from things like this being something which increase engine strength. >I agree that it may be productive if the engine respond to the user of the input >that can tell it that some position is drawn but I think that in most positions >the user does not know important details like that so the main advantage for the >user is by fully automatic analysis and report with no conditions by the user. > Maybe it's not extremely frequent but it's very annoying when it happens. Vas >Uri
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.