Author: Gerd Isenberg
Date: 14:35:30 10/07/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. > > >>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. In Dos-IsiChess i did incremental update of a 64-byte board, 32-bitboards, redundant 64 32-bit piecesets, some mapping arrays, hung and en-prise stuff. All squares with changed attacked controls got updated. It got a bit ineffecient if a lot of squares changed their control status after a move - and of course as you mentioned, if all the stuff is not needed at all. In current MMX IsiChess i only update a few bitboards and material values/masks and hashkey. I didn't even use a "normal" 64-int array or 0x88 board representation. All other stuff on the fly. Some important and often used stuff is stored. That's fine, but often things got calculated more than once a node. E.g. AnyAttacks for legal move generation uses some combined attack fills with a set of Rooks/Queens and in eval (and movegen) i use the single pieces attack getters, since the "design" is still from rotated. With AMD64 and probably with SSE2 combined with general purpose, i will try to avoid multiple calculations of Kogge-Stone fills. But i will stay with minimal incremental update and do disjoint attack fillers as well for single pieces and directions once per node and store them for further use. Even if i do some things for "nothing", they are at least calculated en- passant, parallel with other stuff. One may implement a more accurate "lazy"-eval threshold. Informations like attacks/defends arround the kings, possible sliding checks where king may only move on the attacking ray, advanced (outside) passed pawns, pinned and trapped pieces etc. are already available. Btw. looking for Xray-attacks: If you have a queen exclusively attacking g7 (not occupied by own piece) and exclusively defended by the king on g8, one may look whether the (stored) disjoint opposite direction attack of the queen has a intersection with the set of own sliding pieces able to move on that ray from the queen to the attack square. Another idea is to do a second set off sliding attack generation, removing all same direction sliders (rooks/queens or bishop/queens of the same color) from the occupied board. Xoring the initial attack set leaves the "Xray" set of one sliding piece in one direction, e.g. the queen. Similar for indirect defences. IMHO disjoint direction attacks have some advantages, e.g. separated left and right sliding attacks, even rook (and bishop) wise from kings. Getting a set of pinned pieces and possible "remove" checker is an easy, unconditional task, same for sliding check targets. > > >>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. At least pruning in Q search. I guess some do a bit more... Gerd
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.