Author: Robert Hyatt
Date: 06:43:18 04/11/02
Go up one level in this thread
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...
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.