Author: Robert Hyatt
Date: 14:55:04 08/22/04
Go up one level in this thread
On August 22, 2004 at 13:08:28, Henk Bossinade wrote: >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. > Think about this. You search 2 plies + q-search, and you play a move that appears to win material. With only two plies, you are _really_ committed once you play the first move, and if the q-search screws up and you discover this after your opponent replies, it is too late to back out. If you search 12 plies, you have plenty of opportunities to change your mind as you have 12 moves between the root and the faulty q-search so that there might be other pathways where you can change your mind without getting killed. IE the idea is that the longer the "combination" of moves, the less forced each one is, in general... > >> >>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.