Author: Henk Bossinade
Date: 10:08:28 08/22/04
Go up one level in this thread
On August 22, 2004 at 12:01:36, Robert Hyatt wrote: >On August 22, 2004 at 11:24:07, Dan Honeycutt wrote: > >>On August 21, 2004 at 17:52:58, Robert Hyatt wrote: >> >>[snip] >>> >>>No x-rays is a serious shortcoming. IE two rooks attacking the same square in >>>battery. If you don't include the second rook I could see how SEE could cause >>>problems. I handle X-rays pretty easily and always did even back in CB days... >> >>Could you not say the same thing for pins? > >It is a less serious problem, IMHO. x-rays are very common. Two rooks or rook >and queen lined up. Ditto for bishops/queens. Or bishops/pawns/queens, and so >forth. > > >> >>I started with a really cheap SEE which was just MVV/LVA with a call to >>InCheck() to see if the captured piece was defended. Using that to cull >>captures in QSearch was a definite help (once I got rid of a bug where I threw >>away the good captures and kept the bad ones) >> >>Buoyed by that I wrote a better SEE that took into account all attackers and >>defenders. No discernable increase in strength. >> >>So I wrote a still better SEE looking for x-rays aka what you do in Crafty. No >>discernable increase in strength. >> >>Now I'm working on adding pins. I keep hoping but I'm afraid it will be another >>no discernable increase in strength. > > >It depends on what you use the result for. If you use it to toss out lemon >captures in the q-search, more accurate is better, but remember that the >q-search is far-removed from the root position. In a normal game, crafty hits >14=15 plies in the middlegame. q-search errors don't seem to be a problem with >a search that deep covering for the mistakes. At blitz it might be worse >although in 5 min games on ICC crafty hits 12 plies in the middlegame a lot, >which still covers for the errors. Why would depth compensate for errors? There can be long stretches without material change, so an inaccurate q-search doesn't seem harmless to me. > >Stuart is reporting the opposite... that SEE is killing his tactical scores. >That is what I can't understand, because the pruned q-search tree should make >him faster and tactically stronger, not the opposite, unless there is a serious >flaw somewhere... > > > > >> >>Really rather frustrating. I keep making what I think should be improvements >>and get no results. >> >>Dan H. > >I found the same with SEE and pins. I did one of these years ago (the comments >in main.c should say where) as Joel Rivat and I were comparing notes early in >my/his bitboard programming. Joel wanted as much accuracy as possible, and >convinced me it was important. Adding pins was not that difficult, but it >slowed the SEE code down and seemed to offer no advantage except in contrived >test positions we created. I threw it out and kept my current SEE >implementation...
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.