Author: Dave Gomboc
Date: 10:38:04 05/14/99
Go up one level in this thread
On May 14, 1999 at 13:21:55, Eugene Nalimov wrote: >On May 14, 1999 at 12:26:19, Dave Gomboc wrote: > >>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 > >According to the IEEE Micro article (sorry, not it's not near me right now, so >all data is from memory), they use only one bound, not two as "standard" >alpha-beta. That means that they use some variant of pv-search/mtd(f). > >Eugene I think they did use mtd(f). Maybe I will ask Jonathan (Schaeffer). 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.