Author: Gian-Carlo Pascutto
Date: 18:35:13 12/02/01
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)
This page took 0.01 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.