Author: Ed Schröder
Date: 11:14:34 10/08/97
Go up one level in this thread
[ razor ] >>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 ? Rebel9 after 11 plies: Be5 -1.50 and Qe5 -2.00 So the answer is yes, 0.74 and 0.48 are highly remarkable. And frankly this +0.48 smells as a big bug as black has nothing IMHO. Other opinions please? >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. Please do... >>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. I don't think so and the only(?) way to test this is to store the whole board in the hash table too and check every transposition with the stored board. Ever done this? To me the higher the NPS the more inaccurate the hash table if there is no special software to deal with hash collisions. The more hash collisions the more chances for a bad move. Wrong theory? - Ed - >>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 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.