Author: Dave Gomboc
Date: 11:47:20 05/14/99
Go up one level in this thread
On May 14, 1999 at 13:39:30, Robert Hyatt wrote: >On May 14, 1999 at 12:40:35, Dave Gomboc wrote: > >>On May 14, 1999 at 10:00:03, Robert Hyatt wrote: >> >>>On May 13, 1999 at 23:00:53, Eelco de Groot wrote: >>> >>>> >>>>Robert, Mr. Hyatt, thanks for all the new info on the 'Deep Blue for consumers' >>>>chip! Does Mr. Hsu already have a name for it? I suppose you could call it 'Baby >>>>Blue' , but maybe that is too innocent a name for this monster... (A topic for >>>>the polls, maybe, choosing a good name?). Regarding your thoughts on 'guts' , I >>>>am not a programmer, but does not the 'soul' of a program reside for a large >>>>part in its positional understanding also? Since the chip can be operated in >>>>parallel to a software program, could it not be used mainly for a deep tactical >>>>evaluation? Letting the program do a 1 ply search on all the positional features >>>>Deep Blue is not very good at, while the chip does a 4 ply mainly tactical >>>>search? It would be up to the programmer then to decide how much weight each of >>>>the two evaluations must get to retain the original character of the program. Am >>>>I making any sense here? >>>> >>> >>>yes... but the problem here is that this is what programs like Fritz/Nimzo/etc >>>do to an extent. They do a lot of work at the root of the tree, and then have >>>a very primitive evaluation at the tips. And they make gross positional >>>mistakes as a result. The _right_ way to search is a good search, followed by >>>a _full_ positional evaluation. And that is _very_ slow (which is why the fast >>>programs don't do this). DB _does_ however, because they do the eval in >>>hardware and the cost is minimal compared to our cost. >> >>"_Right_" depends on what works the best. If you find assumptions that carry >>over to all of the leaf positions that matter, and save yourself from the cost >>of eval at each one of them, you will be much faster. Sometimes a leaf position >>that matters will get hit, and you get toasted up. Tough one. :) Zobrist >>hashing is no different. I don't think it is categorically an error to do such >>a thing. >> > >I can't think of a single things that I can evaluate at the root, and then >expect for that to still hold 20 plies into the tree. Not one single thing. >Not even the fact that we are in an opening, or middlegame, or endgame position, >because a _lot_ can happen 20 plies from the root. And if you watch Crafty play >on ICC, in blitz games it generally searches 9-10 plies all the time, except >for when it reaches simpler endgames where this goes up to 15-20. And for those >9-10 ply searches, the PV is often 20+ moves long. What would you notice at the >root and expect that it _still_ applies that far away from the root? Very >little, IMHO. Good argument, but what if we decide to to this e.g. 2 or 4 ply above the leaves instead of at the root? Now the error is reduced, and the time savings are still mostly present. Dave
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.