Author: José Carlos
Date: 08:51:07 12/03/01
Go up one level in this thread
On December 02, 2001 at 21:35:13, Gian-Carlo Pascutto wrote: >Okay, > >this 'Fritz 7 is buggy' thing is getting on my nerves enough >that I'm going to take the time to fully explain it. > >I can't peek in the Fritz source code of course, but I have >a pretty good idea what they are doing in Fritz 7 that they >weren't doing in previous versions, and what some people are >perceiving as bugs. > >Note that Fritz 7 often has truncated PV's, e.g. at a 12 ply >search it only displays a 2 ply PV. And sometimes there are >bogus moves in there (but never the first, which is the one >that matters). The same bogus moves are sometimes pondered upon. >Note also that prior Fritz versions did not have those problems. > >I am faily sure that they are adjusting the alpha/beta values in >the search based on the bounds stored in the hashtable. >The technique itself is faily wellknown. The AlphaBeta in the MTD >papers has it, and I have seen several programs which applied it >too. > >Basically, if during the search you get a hashtable hit which >tells you that this position is 0.5 pawns 'or more' advantage, you >raise your alpha (alpha is the value that says: a move must be >_better_ than this to become the new mainvariation) to 0.5 and prune >away everything that is less. > >This is, AFAIK, theoretically sound. The only problem is that if >the value of this branch was _exactly_ 0.5, you will also have pruned >away your mainvariation. This doesn't matter for the result of the >search, as we are only interested in the value of a branch. But we >will not be able to print out nice long mainvariations. The best >we can do is to try to reconstruct it from the hashtable, but the >moves in there are not always reliable, especially if the search >was failing high or low. > >So, why do this adjustment if it ruins the mainvariations? Simple. >It makes a program (I tested it on mine, but I'll suppose it's fairly >constant) at least 10% faster with no additional effort and no other >effects like worse positional play or anything. > >10% is a _LOT_ for a highly optimized program like Fritz. > >You win 10% but you lose guaranteed mainvariations. It's a design >tradeoff. > >My main beef with this method, and the reason why I only use it in >a limited way myself is that _I_ cannot look up the full variation to >see what position my engine evaluated to arrive at the current score. >And sometimes you ponder the wrong move. Big deal. As the people who >were in Leiden can attest, Sjeng had the same several times versus >The King and it certainly did not affect it's play for the worse! > >For a user, it should not actually matter _at_ _all_, because one >should never trust or use anything but the first move in the mainvariation >anyway. > >I find it redicolous that people here are complaining and calling >the Fritz 7 engine buggy (let's just not talk about the GUI ;) because >it does this, while I never saw anyone complaining about, for example, >Anmon, which displays much worse mainvariations because it uses similar >tricks. > >It's a design tradeoff. If you don't like it and want different >tradeoffs (like an >10% slower Fritz) complain to ChessBase. > >But _don't_ call it a bug, because it isn't. > >-- >GCP (not paid by ChessBase, just fed up with the reigning 'I don't understand it >so it must be broken' attitude) Curiously, I just removed this alpha uptate some days ago because I didn't like the buggy pv's. I have the 'feeling' that the wrong pv's hurt next ply search because I lose information. I admit I didn't test it. I just followed an instict :) I should test with and without alpha updating and see which is best, but I just can't believe that 10% you talk about... 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.