Author: Amir Ban
Date: 04:08:01 10/08/97
Go up one level in this thread
On October 08, 1997 at 03:06:49, Ed Schröder wrote: >>Posted by Amir Ban on October 06, 1997 at 20:27:44: > >>In Reply to: Re: Let's analyze move 36 posted by Ed Schröder on October 06, >>1997 at 14:28:24: > >>On October 06, 1997 at 14:28:24, Ed Schröder wrote: > >>>On October 06, 1997 at 12:07:49, Amir Ban wrote: > >>>>On October 05, 1997 at 07:06:03, Chris Whittington wrote: >>>> >>>>> >>>>>On October 05, 1997 at 04:08:43, Amir Ban wrote: >>>>> >>>>>> >>>>>>Let's try to analyze the critical variation in DB-GK game 2. The move is >>>>>>36 (axb5 was played, don't confuse it with move 37). >>>>>> >>>>>>The variation to look at is after 36. Qb6 Qe7 37. axb5 Rab8 38. Qxa6 e4 >>>>>>39. Bxe4 Qe5. What does Black have here ? >>>>>> >>>>>>At ply (or whatever) 10, DB gives this PV: >>>>>> >>>>>>Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4 Qe5 Bf3 (at lower depths it tries g4) Bf3 >>>>>>Rd8 Qa7 Qxc3 Bh5 +0.74. >>>>>> >>>>>>At ply 11, there is no PV and the eval is +0.48. >>>>>> >>>>>>This variation was mentioned by Seirawan in his analysis, and the GK >>>>>>team used Hiarc & Fritz to analyze it to death. >>>>>> >>>>>>Junior, by the way, likes an intermediate 37...a5, which creates the >>>>>>same position but with Ra2 misplaced. >>>>>> >>>>>>What do you make of this ? >> >>[snip] > >>>>Ed, how about giving this analysis a shot ? > > >>>Here is the text from my home page. >>>To me this is the longest defense. > >>>- Ed - > >>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>>Rr6/5kp1/1qQb1p1p/1p1PpP2/1Pp1B3/2P4P/6P1/5K2 w - - id DEEP BLUE - >>>Kasparov,G; > >>>Analysing this with Rebel we tried to find out the longest defense >>>till the draw (repetition) would be found. Well it is at least 36 plies. >>>Even for DB super machine that's too much. > >>>The line goes like this... > >>>45.Ra6? Qe3! 46.Qxd6 Re8! 47.h4! h5! 48.Bf3 Qc1+ 49.Kf2 Qd2+ 50.Be2 Qf4+ >>>51.Kg1 Qe3+ 52.Kh2 Qf4+ 53.Kh3 Qxf5+ 54.Kh2 Qf4+ 55.Kg1 Qe3+ 56.Kf1 Qc1+ >>>57.Kf2 Qf4+ 58.Ke1 Qc1+ 59.Bd1 Qxc3+ 60.Kf1 Qc1! 61.Ke2 Qb2+ 62.Kf1 Qc1 > >>>Note 60..Qc1! > >>>It's a (quiet) non checking move. Perhaps the reason why no >>>program can find 45..Qe3 with a draw score? > > >>Ed, you're on the wrong page. We are talking about the controversial >>move 36. > > >Ok... > >With Rebel9 Power Analyse I have tested both 36.Qb6 and 36.axb5 till >iteration 17. Results: > >17.00 1.20 Qb6 Rd8 Be4 Qe7 axb5 Rd6 Qa5 >17.00 0.62 axb5 axb5 Qb6 Rxa2 Rxa2 Bc7 Qe6+ > >Both analysis stopped at ply 17 after about 3 hours. > >Does this help you? > Yes, thank you. But it would be even more interesting to follow the variation Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4 Qe5 and look what you find there. Remember this is what DB was thinking about, actually beginning at the first iteration it does (ply 8) after 1 second ! With Black giving up 3 pawns (actually 2 since one is regained easily), it evaluates it as +0.74 on ply 10, finally +0.48 on ply 11 (see my original post). It's a remarkable choice, but what is it based on ? If it's tactical, a PC program starting with Qe5 (8 plies less to calculate) should find it. Do you ? If it's positional, your program is known to have good judgement in this kind of position. Kasparov tried it with Hiarcs and didn't see the explanation. Hiarcs doesn't come even near to the DB evaluation. I told him DB's eval must have been positional, and that they probably had very high penalties for open king positions. His answer: "Then how could it play moves like g5 in the 1st game and b4 in the 4th ?". >Perhaps you can (again) explain your point of view as I didn't get it. > >What I see is a remarkable score difference of 0.58 Actually more since DB was considering a line for Qb6 that you consider inferior for Black. > which in comparison >with Deep Blue can have many reasons. Please pick a few... > >1.. Perhaps Deep Blue has seen more? This is one hypothesis that we can settle with the information I am providing. >2.. Perhaps Deep Blue evaluation versus Rebel differs a lot? >3.. Perhaps Deep Blue evaluation sucks here? >4.. Perhaps Rebel9 evaluation sucks here? >5.. Perhaps there was a bug? (It wouldn't be the first time) >6.. Perhaps hash collisions? > >My personal opinion... >1. 60% >2. 25% >3. 0% >4. 0% >5. 5% >6. 10% > >Too many explanations to call move 36 fishy :)) I agree on this part. There are also problems with the timing that I discussed elsewhere. > >To point 6 the following... >I always wondered how DB handles hash collisions as with 200,000,000 NPS >you can bet on it that this subject need VERY special attention in my >opinion and is very hard to judge if things are programmed well. > >Rebel on a fast Pc does 100,000 NPS and I sometimes really wonder if >the hash table operates in an acceptable way with 100,000 NPS. After >all with hashing we try to put 64 bytes (the board) into 6-8 bytes (the >hash key). > >As a result (I have tested it) you get many hash collisions even if I >extend the hash key to 8 bytes. This all is with 100,000 NPS. Sure I >have built-in some checks, but is it sufficient to catch them all? > Don't believe it. The fact that hash collisions occur does not mean that it affects the PV, and if it does, it is a really freak accident. I do 48-bit hashing with almost no validation. If you wait for my program to fail because of that you will get old in waiting. >Now DB is advertised as a 200,000,000 NPS machine. >So 2000 x faster than 100,000 NPS. >So also 2000 times more hash collisions? >And is it all handled well? > >And how to judge if hash collisions are handled well? > >In the past I have made a special version to test the hash table which >ALSO stores the whole board in the hash table. Every transposition was >carefully checked with the current board. Problem, a speed decrease of >factor 20-30 or so. Also a very limited hash table size because of the >64 extra bytes for every hash entry. > >Open question: Does our hash table software needs to be polished again >because of todays faster Pc's and bigger Ram? > >- Ed - Amir
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.