Author: Dave Gomboc
Date: 09:26:19 05/14/99
Go up one level in this thread
On May 14, 1999 at 11:05:06, Albert Silver wrote: >On May 14, 1999 at 10:02:50, Robert Hyatt wrote: > >>On May 13, 1999 at 23:49:59, Albert Silver wrote: >> >>>On May 13, 1999 at 22:18:59, Robert Hyatt wrote: >>> >>>>On May 13, 1999 at 09:58:12, Robert Pope wrote: >>>> >>>>>On May 13, 1999 at 09:14:48, Robert Hyatt wrote: >>>>> >>>>>>On May 13, 1999 at 09:10:05, Torstein Hall wrote: >>>>>> >>>>>>>I think a DB chip will kill all the Fritzes, Rebels, Nimzos, Juniors and Hiarcs >>>>>>>of this world. What is the point in developing, or buying, something that is a >>>>>>>lot weaker than the "Micro Monster" :-) >>>>>>> >>>>>>>But perhaps it could be made with a programming interface, letting other >>>>>>>programs use it for search, and add their own evaluation functions etc.? >>>>>>> >>>>>>>Torstein >>>>>> >>>>>> >>>>>>This can't be done... the _hardware_ does the eval, and the last N plies >>>>>>of the tree search. All that could be modified would be the first few plies >>>>>>of the search, (and the extensions) since that part is done in software. But >>>>>>the "guts" of the thing will _always_ be deep blue. It can only evaluate the >>>>>>things that the hardware was built to do, and no more. The search and >>>>>>quiescence search can only behave like the chip is built with no flexibility. >>>>>> >>>>>> >>>>>>Evaluation weights can be changed, but new things can't be added... so no >>>>>>matter what you do, you end up with a 'deep blue' program... >>>>>> >>>>>>Bob >>>>> >>>>>In theory, though, how feasible might it be for Hsu to create a modified DB >>>>>"searcher" chip that just did the make/unmake part of the search? When it gets >>>>>to the eval part, instead of the lightning-fast hardware eval, it sends out >>>>>current position information, and waits for a software eval to be returned. I >>>>>know a software eval would cause a huge performance hit, but wouldn't the faster >>>>>move generation and tree travel still give it a nice advantage over a pure >>>>>software program? >>>>> >>>>>I remember the article mentioned something about a hardware trap-door in the >>>>>chip that could potentially be used to add a missed eval feature to the search. >>>>>It seems like that idea ought to be extendable to adding a software evaluation >>>>>or evaluation supplement. >>>>> >>>>>Rob >>>> >>>>This would make no sense to do... IE the speed of the thing comes from the >>>>hardware search _and_ hardware eval. Take the eval to software and you lose >>>>_everything_. IE in crafty, Make/UnMake account for well under 20% of the total >>>>search time. Doing that in hardware would hardly make me any faster at all. >>> >>>This does bring to light another question: would Hsu be planning (though this is >>>tremendously speculative at this point) on ever improving on the actual DB >>>program? Or would improvements, if any, only come in the hardware area? i.e. >>>Improving speed. >>> >>> Albert Silver >> >> >>I would see no reason why the "chip" wouldn't track hardware advancements. IE >>every couple of years, it would double in speed. And then there is the issue of >>'tuning the evaluation' since the evaluation 'weights' are all 'soft' and are >>modifiable... > >What I meant was, would Hsu bring in new knowledge to the program, or modify >existing algorithms, or would he be leaving it as is, and merely (nothing wrong >with this, just curious) fine-tune the eval and keep the chip's technology up to >the ever newer standards? I would be very curious to see DB using Alpha-Beta >though I don't know how big a change that would imply. As I recall, you said >that Hsu abhored any kind of shortcuts that might give cause to an oversight. > > Albert Silver Alpha-beta wouldn't cause any oversights that minimax would catch. I would be extremely surprised if he did not include alpha-beta on it already. Dave
This page took 0.01 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.