Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Let's analyze move 36

Author: Ed Schröder

Date: 00:06:49 10/08/97

Go up one level in this thread


>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?

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 which in comparison
with Deep Blue can have many reasons. Please pick a few...

1.. Perhaps Deep Blue has seen more?
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 :))

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?

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 -



This page took 0.04 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.