Author: Christophe Theron
Date: 23:51:09 07/26/00
Go up one level in this thread
On July 26, 2000 at 22:27:05, Robert Hyatt wrote:
>On July 25, 2000 at 15:24:04, Alvaro Polo wrote:
>
>>On July 25, 2000 at 06:23:51, Ralf Elvsén wrote:
>>
>>>On July 25, 2000 at 05:05:44, blass uri wrote:
>>>
>>>>>
>>>>>Alvaro
>>>>
>>>>Your calculation is wrong because of diminishing return from speed.
>>>>
>>>>Uri
>>>
>>>Right or wrong belongs to pure mathematics. Here we need an estimation
>>>of the uncertainty. If a result is in the right neighbourhood
>>>it's usable.
>>>
>>>Ralf
>>
>>I am going to modify my "I am wrong" assessment. DBJ was making 750,000 nodes
>>per search, and CT 375,000 nodes per search, but DBJ was using only 1 second and
>>CT 22 secs per search. This difference compensates the weak CPU being used by
>>CT. I hence believe that this is equivalent to DBJ against CT (under a powerful
>>P3) if both were using the same time per search (DBJ using equal time
>>compensates the P3-Pentium 150Mhz difference). Then the full DB, at 200Mnps
>>rather than 750Knps would be about 560 Elo higher than CT on a modern machine,
>>assuming that diminishing returns don't affect comp-comp matches, something, on
>>the other hand, that has never been proven wrong.
>>
>>Alvaro
>
>I don't want to go deeper into the argument, but I can offer better numbers.
>
>WebDB was supposedly using one chip according to Hsu. Which would probably
>be one of the later chips at 2.4M nodes per second. At 1/4 of a second for
>downloading eval terms, that leaves .75 * 2.4M = 1.8M nodes per second.
>
>He said other things were intentionally broken (no repetition as it had to
>be stateless to work on the web) and many extensions were 'effectively'
>turned off as they don't enable them for very quick searches for whatever
>reason...
>
>But I'd definitely go with 1.8M nodes per second as an upper bound, 1.5M
>as a lower bound (assuming a 20mhz chess chip).
That makes the picture only worse for poor DBJr.
Chess Tiger was computing in average 375,000 nodes each time it had to play a
move.
DBJr was computing 1.5 MILLION nodes (or more) each time it had to play a move
(your own numbers).
That means that DBJr had a computational advantage of 4 times, at least, in
number of nodes.
We have heard many times that DB's evaluation was made of thousands of terms
(wasn't it 8,000 terms or so?), that this evaluation has been tuned by
grandmasters, and that, as it was built in the chips, they could compute
everything they wanted for free.
So the microcomputer programs are supposed to have an inferior evaluation
function, at least that is what the propaganda machinery told us.
If it is really the case, with a computational advantage of 4 times in number of
nodes and your superior evaluation function, then you are supposed to CRUSH your
micro opponent, isn't it?
You crush it because:
1) in every position you look at your evaluation is better than your opponent's
2) you can look at many more positions than your opponent
But it simply did not happen. There is the 1.5-1.5 result against Tiger (you can
even count a 2-1 victory for DBJr if you want). And don't forget that, with a
faster notebook, Rebel won 3-0.
So were is the bug?
Using the excuse that the evaluation function was weaker than the real DB is
just an insult to us chess programmers. Maybe the excuse works for people that
have no chess programming experience, but it does not work with me.
You can do the following experiment: take your chess program and weaken its
evaluation by just taking into account the material balance, the pawn structure,
and centralization of pieces (with very simple piece square tables). Allow this
weakened version to compute 4 times the number of nodes that the normal version
is allowed to use, and let them play against each other. The "weak" version will
win by a large margin, because the 4 times handicap in number of nodes is simply
overwhelming.
What I'm saying is that weakening the evaluation function is not enough to spoil
a 4 times advantage in number of nodes, unless of course you tell your program
that a rook is worth 2 pawns and a queen is worth 0.5 pawn.
So I'm not going to buy the "weak evaluation" excuse.
The same for being stateless. This is a problem for the evaluation of draw by
repetitions and 50 moves rule, but it is not relevant in the games I have
posted.
Or the problem is somewhere else. I don't think not doing extensions is the
problem (especially with the number of nodes advantage) but probably not doing
any forward pruning is not a bright move...
But anyway... As I said, I have just seen 2 chess programs fighting. I did not
notice that one of them was so much smarter than the other one.
My conclusion is that the only advantage of Deep Blue is its speed. I don't
believe its evaluation is superior.
And that the speed superiority is somehow spoiled by the lack of serious pruning
schemes and by the use of the useless flashy "singular extension".
Microcomputer programs have serious chances against one DB chip.
Of course, if Hsu produced new chips with state of the art technology, they
would run much faster and the situation would be changed. But is this going to
happen?
Christophe
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.