Author: José Carlos
Date: 09:49:32 11/09/01
Go up one level in this thread
On November 09, 2001 at 12:32:36, Uri Blass wrote: >On November 09, 2001 at 11:26:09, Gian-Carlo Pascutto wrote: > >>On November 09, 2001 at 11:01:00, William Penn wrote: >> >>>No! That is not correct! >>> >>>Only the Fritz 7 (with MMX) engine produces outright analysis blunders, based on >>>my long experience of many years, running many different engines then >>>scrutinizing the analysis carefully. >> >>Look harder. >> >>Anmon (or any MTD searcher), and Sjeng versions before 12 would do the >>same. I'm sure there are other engines. Fritz 7 is now one of them. > >I do not understand what MTD has to do about it. In MTD(f), you don't build the PV in the recursive search, because you don't have exact values, you only fail high and low all the time. So, you have to get your PV from the hash table, and moves in the hash table can be weak. >I do not understand the reason to show a main line when black finish with a >stupid queen sacrifice that is captured in the last ply of the pv. I can't say for Fritz, but I can give some possible reasons: - if you cut the search due to a hash hit, and you continue getting moves from the hash table to build the PV, you can have weak moves for the same reason as MTD(f). - if you fail high in the root, you can decide not resolving the fail high, and try the rest of the moves before. If noone of them fails high, you don't resolve the fail high and move on to the next ply. PV's based on fail highs can contain blunders. - it is even possible (although not very probable in Fritz) to have move in the pv array from previous searchs and, due to a bug, include them in the current pv. This is a harmless bug, because it only affects the printed pv. >The main line can have mistakes in the last plies because the program did not >search deep enough but the relevant mistake is not a result of not searching >deep enough. > >If the program shows stupid moves in the last plies that are not result of a >shallow search and the static evaluation(without search) of the final position >in the main line is not identical to the evaluation that the program shows >then it is better not to show a main line because the main line is supposed to >be something logical(otherwise the program can choose random moves for the main >line only to print something). > >I understand having a positive evaluation for white when the main line is >finished with mate for black because there are programs(including Crafty) that >do not evaluate mate in their evaluation function but I do not understand seeing >evaluation function of +2 for white when the static evaluation of the final >position in the main line has nothing to do with +2 unless the final position in >the main line is read from hash tables and in this case the evaluation of the >final position of the main line after search to the right depth should be +2 or >at least the difference between it and +2 should not be too big(there can be a >difference because the program may do preprocessing). > >Uri Additionally, the position after the last move of the pv is not necessaryly the position the program evaluates and backs up to the root. I, for example, print always n moves, where n is the nominal depth, no matter how much I extend or what I do in qsearch. José C.
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.