Author: Robert Hyatt
Date: 12:02:28 05/14/99
Go up one level in this thread
On May 14, 1999 at 14:47:20, Dave Gomboc wrote: >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 How much error will you accept? IE most of my 12 ply searches have PV's that are much longer... say an average of 20 plies. is searching 20 plies beyond the 'root eval' bad? I think so. Is only searching 16 plies beyond a 4-ply "root eval" bad? I _still_ think so. And if you run that eval out to 10 plies the computational cost starts showing up...
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.