Author: Robert Hyatt
Date: 13:49:36 10/08/03
Go up one level in this thread
On October 07, 2003 at 13:27:30, Russell Reagan wrote: >On October 07, 2003 at 13:08:28, Anthony Cozzie wrote: > >>I'm sorta disappointed, actually. > >YOU could always make the statement :) > > >>I think I said that it was harder with bitboards ;) However, it is not exactly >>_easy_ to write in any representation. >> >>The logic runs like this: A big part of capture evaluation is xray: if I have >>Ba1 + Qb2, my pawn at e5 is defended twice, not once. With bitboards, figuring >>this stuff out is very annoying, because get_attacks_bishop(E5) will not find >>the bishop. To make things even more annoying, imagine Pf6, Pe5, Qb2, and Ba1 - >>now we have to deal with pawns as well. With a 64 byte or 0x88 board, you just >>keep scanning. This is why Zappa's capture evaluation actually doesn't use the >>bitboards (slight fib, but mainly it scans). > >I was going to recommend that you could still do scanning quite easily using >bitboards, and it shouldn't need to be any slower than an 0x88 approach, if you >are careful. xray attacks are trivial in bitboards, in a SEE function. I have done this in Crafty from the very beginning (ie Swap() and SwapXray()). I have a target square I am applying SEE on. When I "use" a capturing piece, if it is a diagonal-mover I can look in the opposite direction (ie instead of square-to SEEtarget, I use the opposite direction to look back in the same direction behind the piece I just used to see if there is another slider in battery. If so, I then add it to the swap piece list. This correctly handles a queen and bishop lined up with the queen first, so that I have to use the queen and then the bishop, in the correct order, which might affect the final result. > > >>I'm working on incremental attack >>tables right now so that I don't have to mess with it. > >Be sure that you can really benefit from the overhead involved, because when you >go incremental, you have that overhead no matter what. If you do things on the >fly, you save work in cases where you don't need it. I know several people >prefer to do things on the fly, but I don't know of anyone that has tried both >ways and uses the incremental approach, but I certainly don't know what everyone >does. > > >>P.S. I believe SEE refers to capture analysis in place of Q search, although >>perhaps its meaning has changed somewhat. > >I thought that SEE, in general, wasn't used in place of qsearch. Of course, >anyone is free to do this and it might work fine, but I think it's used more for >move ordering usually. That's what I do, although in the middle 70's I used a SEE instead of a q-search for a while and it worked surprisingly well. But it misses too much in terms of overloaded pieces, pinned pieces, and the like.
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.