Author: Anthony Cozzie
Date: 15:14:42 10/07/03
Go up one level in this thread
On October 07, 2003 at 17:35:30, Gerd Isenberg wrote: >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. its mostly done already. The main annoyance is that i have to write everything twice because of different asm conventions. >> >> >>>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.