Author: Christophe Theron
Date: 13:04:43 07/28/00
Go up one level in this thread
On July 28, 2000 at 02:10:52, Alvaro Polo wrote:
>On July 27, 2000 at 23:51:40, Christophe Theron wrote:
>
>>On July 27, 2000 at 05:05:43, blass uri wrote:
>>
>>>On July 27, 2000 at 02:51:09, Christophe Theron wrote:
>>>
>>>>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.
>>>
>>>I guess that if you do the same experiment for slow searchers you may find that
>>>4 time handicap in nodes is not overwhelming.
>>
>>
>>
>>Slow searcher of fast searcher, so far no known program has escaped the gold
>>rule that doubling the clock speed increases the elo level by 70 points (more or
>>less). Check the SSDF list.
>>
>>
>>
>>
>>
>>>One possible reason is that you can see tactics by smart evaluation:
>>>Here is one example:
>>>
>>>rn4k1/ppN5/8/8/8/8/PP6/R3K3 b Q - 0 1
>>>
>>>A slow searcher may see at evaluation time that the black rook cannot escape
>>>when a fast searcher needs to search in order to see it.
>>
>>
>>
>>You probably underestimate what a "fast" searcher can understand. You should
>>also not overestimate the importance of such knowledge. When it happens, it is
>>important to have the knowledge, but it does not happen often. 95% of the time,
>>searching more nodes solves the problems. 5% of the time, very specific
>>knowledge is needed. And the amount of knowledge needed by these 5% is HUGE and
>>would slow down very badly any program.
>>
>>In your example, the evaluation function of a program might not be able to
>>understand the problem, but a 1 ply deep search will immediately see the
>>problem. So a "fast" searcher looking 1 ply deeper than the "slow" one will get
>>it as well. And will understand many many other positions where specific
>>knowledge has not been added.
>>
>>Also, in your example, there are other criteria that would very probably tell
>>the program to avoid the position, without searching. Chess Tiger for example
>>would avoid the position because the black rook has a very bad mobility.
>>Sometimes, exact knowledge is not needed in order to get the right result.
>>
>>If "knowledge" could overcome search in general, you would see only slow NPS
>>programs on the top of the SSDF list. It is not the case.
>>
>>
>>
>>
>>
>>>It is also interesting to know if the result is not dependent in the number of
>>>nodes.
>>>Do 100 nodes against 400 nodes per move with simple evaluation give the same
>>>result as 100000 nodes against 400000 nodes with simple evaluation?
>>>
>>>10000 against 400000 is still blitz so it is easy to get a lot of games and see
>>>if there is a significant difference.
>>
>>
>>I think you mean 100,000 against 400,000 ?
>>
>>I have not done the experiment but I think the result would be 70% in favor of
>>the 400,000 nodes. 4 times means a 140 elo points difference (+70 by doubling).
>>140 elo points translates to a 70% winning percentage.
>>
>>
>
>Interesting. A 70% winning percentage in 3 games is 2-1, and you told that we
>could consider 2-1 to be the result of your minimatch against DBJ. This would
>indicate that, at equal NPS, Chess Tiger would be more or less equal than DBJ.
>Of course there is not that equal NPS unless you force it. DBJ makes 1,500,000
>NPS. I don't know about CT NPS (sorry). Perhaps 200,000? If so, DBJ would be
>about 200 Elo above CT on modern hardware.
>
>Alvaro
Chess Tiger on a fast Athlon should reach 300,000 NPS. Also remember that DB
does less pruning.
I think both opponents should be rather close in strength, as would be many top
microcomputer chess programs.
But my main point is that Deep Blue is not the divine thing some want us to
believe. It's just a very classical chess program with a higher NPS.
No need to marvel at the singular extension stuff. When you compute 100 times
faster than your opponent, you kill him anyway. But it's not sexy enough, and
Hsu and co needed something more flashy. Singular extensions does the trick:
1) it is not done by anybody else (for the good reason that it is ineffective).
2) we can afford to use it as we are so superior in NPS anyway.
3) from time to time we will find a 30 plies combination, and this is what we
need to build a legend around Deep Blue. Everybody will be astounded. Maybe some
naive chess programmer is even going to fall in love with it and will sing
propaganda for us for the rest of times.
Christophe
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.