Author: Bas Hamstra
Date: 14:53:47 04/11/02
Go up one level in this thread
On April 11, 2002 at 09:43:18, Robert Hyatt wrote: >On April 11, 2002 at 04:32:02, Bas Hamstra wrote: > >>On April 10, 2002 at 18:01:23, Robert Hyatt wrote: >> >>>On April 10, 2002 at 16:38:49, Gian-Carlo Pascutto wrote: >>> >>>>On April 10, 2002 at 00:27:54, Keith Evans wrote: >>>> >>>>>When Hsu designed the move generator for Deep Blue he added extra hardware so >>>>>that he could generate checking (even discovered checks) and check evasion moves >>>>>more quickly than his first move generator could. (Compare the diagrams for the >>>>>square transmitters and receivers in the IEEE micro article to those in his >>>>>thesis and to those describing the Belle generator.) He could have generated >>>>>these moves without the extra hardware and design time by iterating through >>>>>moves and throwing away moves which didn't meet the criteria, but apparently he >>>>>thought that the performance of the move generator was important enough in these >>>>>cases to justify adding the complexity. >>>>> >>>>>What's the general opinion on this? Was this time well spent, or was it a waste >>>>>of time? I searched for information on what programs typically do during qsearch >>>>>and couldn't find much of anything directly related. It seems like he would have >>>>>simulated this before commiting to design, and perhaps discussed it publicly >>>>>with some top programmers. >>>> >>>>In the qsearch, being able to generate only capture moves fast is >>>>a nice speed advantage. If you want to do checks/check evasions too, >>>>you'll have to generate these moves somehow. If you have to fall >>>>back to your standard movegen, that'll come with a speed loss, so >>>>it makes sense to try to avoid that. >>>> >>>>Since qsearch tends to amount to a large % of the nodes searched, >>>>this sounds like an understandable decision. >>>> >>>>Note that there are usually a lot less captures+checks/evasions than >>>>normal moves. >>>> >>>>-- >>>>GCP >>> >>> >>>we did that in Cray Blitz... But in Crafty I dumped the big q-search early >>>on (version 13 I think) and went to a simpler q-search with a more complex >>>base search... The checks in q-search find some cute things, of course. But >>>they also miss a lot. >>> >>>I don't do it at present because the q-search is highly selective anyway, >>>and it has significant errors present in it. Trying to make something that >>>has lots of known errors in it even bigger seems (to me) to be inviting >>>trouble. >>> >>>I occasionally miss a tactic that the old q-search would see. I also find >>>a tactic that the more accurate search finds that the old one missed. I have >>>not (yet) been unsatisfied... >>> >>>The main thing checks in the q-search helps to find are the mates in 30 and >>>so forth that rarely happen in real games... >>> >>>IE I have seen chessmaster do a 4 ply search in 4 minutes, and get totally >>>creamed by a simple positional trap, because it was following checks out to >>>impossible depths. Of course, Crafty does the opposite as well, by missing a >>>very deep tactic due to the simple q-search. But since I see no advantage in >>>either approach, I like "simple is better". :) >> >>Sounds reasonable. However I saw you complain many times about nullmove hiding >>many mate threats. Well, that IS related. With such a mini qsearch you create >>dangerous blind spots. Question is are you willing to sacrifice a little >>positional depth to get rid of those blind spots. Personally I am. >> >> >> >>Best regards, >>Bas. > > >I don't see such blind spots very often today. I did at 5K nodes per second >and even at 30K. But not at 1M, which helps a lot... Less, maybe. But the importance of 0,25 ply extra overhead is also less with 1M, and wouldn't you *love* to play moves like Ponomariov's Nf6!! ? Bas.
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.