Attack table musings

[Tony van Roon-Werten]

what if that killer move after the capture sequence ends is not a check?
i think that the point of recapture extensions is to avoid delaying capture/recapture sequences anywhere in the tree,not just at the tips.
if cap/recap is done near the root, just to delay something bad at the tips(by some quiescent move),the one without recapture extensions wouldn't see it even if it does search all captures and checks.
one may also say singel response extensions are not important if you do
long checking sequence in qsearch. i also do this extensions for the same reason i do recap extensions.

True.

It's a matter of testing wich works best for you. Wether not extending and searching deeper overall outweights the missing of some quite killer moves.

I'm pretty sure it's different for every engine, and even needs to be re-tested after (big) search changes.

Single reply extensions are different imo, because they don't add so much nodes to the searchtree, so your overall searchdepth isn't much higher compared to not extending.

Tony

[GeoffW]

Hi

I have got a bit of free time again, so I came back to thinking about attack tables.

I was considering what I would need to do to expand my usage of Ed's attack table idea to make a SEE function and also to use it for a board square control function

On Ed' page (http://members.home.nl/matador/chess840.htm#HW) he describes how he is using 8 bits so that he can then use look up tables to find out who controls the square. Using a scheme like

Code: Select all

   ---------------------------------------------------------------------------
   |         |         |         |         |         |       |       |       |
   |    7    |    6    |    5    |    4    |     3   |   2   |   1   |   0   |
   |         |         |         |         |         |       |       |       |
   -------------------------------------------------------------------------
   |         |         |         |  Knight |        |||      |       |       |
   |  King   |  Queen  |  Rook   |  Bishop |  Pawn  |||  Count  3 lsb bits   |
   |   Bit   |   Bit   |   Bit   |   Bit   |   Bit  |||      |       |       |
   ---------------------------------------------------------------------------

The snag with this is that for example if we have a count of 3 and the rook and the knight/bishop bits are set, this is ambiguous as it might mean 1 rook and 2 bishops or 2 rooks and 1 bishop.

Surely this would introduce some gross inaccuracies ? I cant see how this wouldnt cause problems ?

Ed also mentioned that the square control table he uses would be given later in the article. I couldnt see that, guess he never got around to documenting it ? I think I need to understand the issue above a little more before I try and figure out what the table needs to look like

Any insights into this would be appreciated ? Thanks

Geoff

[Sven Schüle]

Hi Geoff,

two bishops and one rook can be excluded for most practical cases (when do two bishops of the same colour attack the same square?).

Changing your example into "two knights and one rook" vs. "two rooks and one knight" makes a bit more sense perhaps.

I think there is a tradeoff between accuracy and efficiency in this case. The difference between NNR and NRR attack (or defense) is not always important, it will only count if a piece is considered to be safe on the target square in one of the two cases and unsafe in the other case.

The same with queens: of course NNQ or NQQ makes a difference but I think there are only academical cases where NQQ attack turns a piece into a hanging piece if NNQ does not yet do so (or vice versa for defense). And NQQ itself is already a very rare case.

Zach Wegner posted about his interesting alternative encoding strategy in the same thread here, I think it is worth some more thoughts.

Cheers,
Sven

[GeoffW]

Hi Sven

Thanks for the reply, yes I didn't pick a very good example as a likely scernario, but you followed my point anyways. The ambiguity also extends to pawns and rooks/knights. The more I think about this encoding scheme the less I like it. When I pick this up again I might try swapping to a scheme more like Zach described.

Geoff