Author: Robert Hyatt
Date: 16:08:18 07/22/00
Go up one level in this thread
On July 22, 2000 at 18:36:50, Dave Gomboc wrote: >On July 22, 2000 at 17:18:19, Robert Hyatt wrote: > >>On July 22, 2000 at 17:00:24, Amir Ban wrote: >> >>>On July 22, 2000 at 16:19:07, Robert Hyatt wrote: >>> >>>>On July 22, 2000 at 16:03:59, Amir Ban wrote: >>>> >>>>>On July 22, 2000 at 15:32:26, Ed Schröder wrote: >>>>> >>>>>>On July 22, 2000 at 14:16:51, Andrew Dados wrote: >>>>>> >>>>>>>On July 22, 2000 at 14:11:20, Ed Schröder wrote: >>>>>>> >>>>>>>>On July 22, 2000 at 13:28:28, blass uri wrote: >>>>>>>> >>>>>>>>>Deeper blue had a positive evaluation before trading queens. >>>>>>>>> >>>>>>>>>The evaluation of Deeper blue was based on Deeper blue's logfile >>>>>>>>> >>>>>>>>>9(6) 3 T=46 34...Qxf1 >>>>>>>>>10(6) 2 T=130 34...Qxf1 >>>>>>>>>11(6) 2 T=168 34...Qxf1 >>>>>>>>> >>>>>>>>>The evaluation when deeper blue started to ponder (hash guess Rxf1) was >>>>>>>>> >>>>>>>>>7 (4) -30 >>>>>>>>>7 (6) -66 >>>>>>>>>8 (6) -50 >>>>>>>>>9 (6) -50 >>>>>>>>>10 (6) -50 >>>>>>>>>11 (6) -48 >>>>>>>>> >>>>>>>>>Deeper blue lost 0.5 pawn in the evaluation and the only reason that I can >>>>>>>>>explain it is that it is a root processor. >>>>>>>>> >>>>>>>>>I guess that something like this cannot happen to Deep Junior because it is >>>>>>>>>probably more knowledge based program. >>>>>>>>> >>>>>>>>>Uri >>>>>>>> >>>>>>>>The behavior you describe is quite normal. After a queen exchange in the >>>>>>>>next move often other more accurate tables are used which may cause such >>>>>>>>score differences. I do the same in Rebel. That doesn't make the program >>>>>>>>a root processor. A root processor is a program that totally (or to a >>>>>>>>great extend) relies on the evaluation on the root. If you read the IBM >>>>>>>>pages it is said DB has something similar (a short investigation at the >>>>>>>>root). That makes DB no root processor. >>>>>>>> >>>>>>>>Ed >>>>>>> >>>>>>>What you just said is pretty much confirmation of preprocessing to me: >>>>>>>'After a queen exchange in the next move often other more accurate tables are >>>>>>>used []'... >>>>>>>If it is done in the search - then no score differences should be seen; if it is >>>>>>>done at root then it is clear preprocessing... >>>>>>> >>>>>>>-Andrew- >>>>>> >>>>>>Yes such ticks are preprocessing. And it helps. But note that in Rebel >>>>>>only a few things are done this way not more than being < 0.5% of the >>>>>>total knowledge. That makes Rebel not a root processor and DB neither >>>>>>which was my reply to header of the subject. >>>>>> >>>>>>Ed >>>>> >>>>>I disagree. >>>>> >>>>>Even if only a small part is preprocessed, the effect here is huge: half a pawn. >>>>>DB played 37... Qxf1+ into an even position and woke up a move later into a >>>>>half-pawn disadvantage. This means that according to its own evaluation Qxf1 is >>>>>a blunder and would never have been played if not for preprocessing. >>>>> >>>>>DB switched from Qe2 (-21) to Qxf1+ (+2) and then learned that it's actually >>>>>Qxf1+ (-48). So Qe2 was clearly better by DB evaluation. >>>>> >>>>>Junior evaluates Qe2 and Qxf1+ as equals. >>>>> >>>>>Amir >>>> >>>>As I said before, there is more than one way to skin a cat. Cray Blitz did >>>>exactly as described, because there I added a bonus for trading queens. But >>>>once the trade was done, the bonus went away on the next search. >>>> >>> >>>Same thing. This may not be preprocessing, but is equally bad. You play a move >>>thinking it is best, only to find when evaluating the resulting position that >>>your second-best move was better. >>> >>>If scores are not comparable, then they are meaningless. >>> >>>Amir >>> >>>P.S. Before somebody jumps on me with a position, I do have some minor >>>dependency on root position in Junior. I don't like it, and will get rid of it >>>eventually. >>> >> >>Scores don't have to be consistent between moves. If I want to trade queens, >>and I give a bonus for trading queens, then after the trade, the bonus is >>gone. But it was _still_ the right move. Alternatively, as I do now, I >>have what is essentially a penalty for too many pieces, and as the pieces >>come off, the score goes up. I don't like the score getting so large in >>simple endings, but it is only a number that guides the search. I may say >>+3, you may say +1.5, but if we play the same moves and win, it really doesn't >>make any difference. > >But if the scores aren't consistent between moves, it's not completely safe to >rely on the bound information stored in the hash table from previous searches. >It seems to me that this is rather undesirable. > >Dave That is why I said that when I change something at the root, I zip thru the hash table and mark the scores as invalid, but leaving the best moves for move ordering. And it causes other problems as well (anything that is path dependent has this issue, and a bonus for a capture is definitely a path dependency). But I was pointing out that you can have different scores with no root processing at all. I did it in Cray Blitz. I didn't like it that much and fixed it in Crafty... sort of...
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.