Author: Fernando Villegas
Date: 11:00:01 04/20/98
Go up one level in this thread
On April 20, 1998 at 09:56:15, Amir Ban wrote: >On April 19, 1998 at 19:33:25, Fernando Villegas wrote: > >>Hi Amir: >>I have just played my first game against Junior -the module in Fritz- at >>a relatively serious rhythm, 40 in 60, game that I lost after 50 moves >>of a very hard fight for him but specially for me, of course, otherwise >>I would be the winner. >>My first impression is that the expression “fast searcher” with which is >>defined even by you in the cd-rom clip is somewhat misleading as much as >>there is some ambiguity in the definition of what it is “fast” search in >>the first place. >>What I saw is that Junior reaches very very soon 12 ply, faster than >>Fritz even if Fritz counts more nodes per second than Junior. Then, I >>thought that the speed of search should not be automatically considered >>like something equal to the count number, but to the ply number. In my >>opinion Junior is fast because he goes very soon to very deep searches, >>not because the great crunching of nodes he does to get that. I can >>easily imagine an even faster computer in terms of nodes, but very slow >>in terms of ply if the search is totally full-width, without any pruning >>at all. In that case the very fact of exponential growing of the tree >>would impede a deep search at all. On the contrary. I can imagine an >>slow thinking machine -like the human brain- reaching very deep levels >>of ply because of an exceedingly good pruning or selective search. >>So, when we say that this or that program is “fast searcher” we are not >>concluding the search of how that program is, as it seem to happens, but >>just beginning with it. We don’t advance even an step saying that a >>program is “fast” searcher in comparison with another that supposedly is >>“knowledge searcher”. If, as I think, fast search equals deep search, >>then there is a pruning device, a selective criteria. And if there is >>such thing, the key to understand the problem is not just to say how >>“fast” the program is, but to insvestigate how the program do so deep >>search. >>So, dear Amir, why don’t you tell us a little bit the way you get those >>very deep searches? >>Fernando > > >Hmmm ... I thought at least you, of all people, would remember the CCR >article you did on Junior. It should have answered that question at >least. Everyone is complaining that the programmers are not talking, but >the truth is that when they talk, nobody listens. I guess that's how >they learned to shut up :) > No, I recalled very well what you said there, but maybe is you now who is forgetting how little of it you said... :-) >I think your question is more likely to be asked by a non-programmer >than a programmer. The Junior depth value measures half-plies, so if you >insist, it's ply 6. I could have called it ply 12 or ply 9 with equal >justification. Since nobody does brute-force anymore, and everybody does >both pruning and extensions, what the depth indicator means is a bit >vague. Very roughly, I would propose this equality: > > Genius depth 6 = Rebel depth 8 = Fritz5 depth 10 = Junior depth 12 You see? This important equivalence was not explained in the interview and now we have got it. >which once said should be forgotten, since it's much more complicated >than that. > > >Deep searches ... > >Junior's lines often come very deep quite soon. It's impressive, I know, >but there is nothing intentional about it. It's a result of search >heuristics that have no special preference for "deep". The real points >about this are usually missed: > >1. The quality of the search is as good as it's weakest part. It's no >good analyzing your PV's to 30 ply if you are likely to fall for an odd >3-mover you overlooked. > >2. Most programs can extend lines to wild lengths, and actually do in >the search, but these lines don't often turn up in the PV. In Junior, >they very often do, so you get to see them on the screen. Junior, being >an alpha-beta program, doesn't know in advance that a line it's looking >at will become the PV, so the fact that PV's tend to be long is an >indication that the search heuristics are doing something right, that >is, they follow what is indeed important in a position. > >Amir Well, Amir, thanks a lot. Precisely this kind of stuff above is what I wanted to know, stuff that was not in the interview, maybe because I did not make the right question or because you did not answered what I wanted. So, don't think we don't remember what programmers say. In fact, precisely because I am very interested in that was the reason of the serie of interviews I made for CCR.
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.