Author: Christophe Theron
Date: 20:51:40 07/27/00
Go up one level in this thread
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.
In the case of 100 against 400, there might be a problem. Very often, a 100
nodes search is not enough to complete ply depth 1, so I'm not sure the
experiment would give anything relevant.
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.