Author: Eugene Nalimov
Date: 12:08:13 05/14/99
Go up one level in this thread
On May 14, 1999 at 15:02:28, Robert Hyatt wrote: >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... In my 8080/z80 program I modified parameters (mainly square-pieces tables) only if something drastically changed on the board - queens were exchanged, king moved more than (I think) 2 squares, etc. And actually I did not re-evaluated the tables immediately - I set the flag that says the first full eval have to do that. Usually there were no need of that full eval, as simple eval (material + crude pawn estimation) was enough fo cutoff. Eugene
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.