Author: Albert Silver
Date: 10:20:12 01/06/98
Go up one level in this thread
On January 05, 1998 at 23:07:27, Bruce Moreland wrote: > >On January 05, 1998 at 17:53:07, Albert Silver wrote: > >>Deep Blue sucks??? That isn't exactly what I said, and if that's the >>impression I gave, then I'd like to clarify. You say you turned off you >>endgame databases. Fine, but what does that have to do with knowledge? > >Ok, please pardon me, I didn't consider what my words implied. > >I asked a question, and if anyone has an idea, that'd be great. I am >afraid that we'll go straight to the traditional "How good would DB be >vs program X" discussion, where X is Hiarcs, Rebel, Genius, or Fritz, >rather than talking about the issue I raised. > >>Disable Ferret's knowledge of the game (or at least most of it) and then >>run it through. How many plies until 59...h5 is clearly and materially >>lost? Not evaluated lost, but materially lost. Why do some programs find >>the solutions to problems faster than others? Is it just because they >>search deeply quicker than others? > >There are people who might claim that their programs are jam packed with >knowledge about stuff like this, but I won't, because mine isn't. > >It tries to understand passed pawns, king position, rooks behind >passers, connected pawns, rook on the 7th, and the like. It has KRP vs >KR tables, and various other tables, but like I said, I turned that off. > With that stuff off, it knows that some KRP vs KR positions are likely >draws, but not much else. > >This is hardly special, and none of this may matter here very much. It >seems possible that this position is resolvable by pure search. > >To answer your specific questions, first it understands that ... h3 is >drawn (returns a draw score), pretty quickly. > >If you play ... h5 and let it search for white, it also seems to >understand that black has real problems, likewise pretty quickly. It >starts out liking Kg5 at +1, and figures out that something is either >wrong with this or looks wrong with this at about 2.0 seconds, and by >2.7 seconds into this search has decided that it's going to go with Ke5. > This starts out at better than +1 and goes up to +2 at the end of a >minute, and is based upon being a pawn up. > >I've run LCTII on about a hundred different versions, and probably 90% >of them have gotten this in less than 35 seconds. The longest any of >these versions took was 101 seconds. This is all on a P6/200. > >I didn't tune for this problem, nor have I ever even really looked at >it. > >So I wonder why DT didn't get it. Did they have a bug? Were they in >time pressure so bad that they couldn't spend a few seconds to find it? >Is their search doing so much full-width stuff that the micros are >actually out-searching them here? Do they have an evaluation hole? I >have no idea. > Quite possible. Everyone knows that in the Deep Blue project they had the entire backing of IBM and were able to devote as much time as necessary to fine tuning their program, but I don't know what the situation was back then. Bob has often explained how he had had to do all of his debugging smack in the middle of an event because he couldn't just go around tinkering with his Cray program on a Cray whenever he pleased. Maybe they had a similiar problem then, I don't know. >>If that was the case, then a program >>like Hiarcs should underperform in test suites (for example) compared to >>power searchers in every test, every single time. That's not the case >>obviously. Take the example of Junior's game against Comet in which it >>played the losing 47...Rxd3. I fed the position after 47.Kg1 to Fritz 5 >>and watched to see how deeply it had to go to see that Rxd3 is LOSING >>(not just when it would choose another move). After 13 plies it >>announces that Rxd3 draws, and after 14 plies it sees that this loses >>outright. I then let Hiarcs 6 look at it, and after 6 plies it says that >>Rxd3 draws and after 7 plies it says that it loses. I'll admit this >>example is unusually extreme, and that there are opposite examples of >>Fritz's searching showing results far faster than Hiarcs. While this >>clearly argues in favor of knowledge based programs, I also don't >>believe that every knowledge ladden will reach the solution at this same >>depth (some may do it at a shallower depth, and some may require an >>extra ply or so). The difference would then be not just a matter of >>knowledge, but also in how this knowledge was administrated (or >>prioritized). My argument wasn't actually about Deep Blue and Deep >>Thought, though I used them for the sake of examples, but on how >>knowledge is used in programs and how it is prioritzed in the evaluation >>function. If a program is juggling 300 elements in a position but >>doesn't know which ones to prioritize, then it's knowledge is useless, >>and might even be a hindrance. But to say that Deep Blue sucks?.... I >>couldn't disrespect Kasparov that much. :-) > >I may be wrong, but I don't think this is a knowledge problem. I think >straight search finds it just fine. If DT didn't find it, it raises >questions about their search, or perhaps they simply didn't have enough >time to find it. It'd be interesting to find out what happened here. > >bruce You're quite possibly right. As I said in my inital post, my mind was meandering somewhat and I began to wonder a little more about DB. You see, programs on micros have to be careful about what they put in so as not to slow down the search too much. DB is different in that it has all the memory it wants so if the DB team decides to put 10,000 positional elements that will weigh-in it's eval, they can perfectly well do so and suffer absolutely no slow down in it's search. At least that is what I have understood from Bob's explanations on it. As the team spent a year working in close conjunction with GM Benjamin (and possibly others), I would imagine they put in a tremendous amount of knowledge (and yes, this has NOTHING to do with Fin4), yet it played some very strange moves, that are either due to bugs, but if they are not then there must be some explanation. The only one that I found was that the problem wasn't in lack of knowledge, but perhaps in the improper prioritization of it. Albert
This page took 0.02 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.