Where to generate Attack Tables

[Edsel Apostol]

I tried maintaining attack tables
in the update() and downdate()
portion after making and unmaking
moves.

It was quite expensive with bitboards,
at least, in my implementation, so
I turned the code off.

Now, I only use attack maps as needed
in eval and believe that is the better
course.

The Chess 0.5/4.x group by the Northwestern
group may have done somewhat of a disservice
to the community by making it seem like
these are normal, prudent and best to have
outside of eval.

I don't happen to think that.

They are expensive to maintain, even
with special-purpose coding.

Has anyone done more studies of
attack-map always-on vs. only-when-needed?

Stuart

I just calculate whatever I need, when I need it.

I will try to implement an incremental attack tables using two bitboard arrays of 64 elements.

I'm thinking of using BitBoard AttacksFrom[64] and BitBoard AttacksTo[64], where AttacksFrom will save the bits attacked from a square and AttacksTo the bits of the squares that attacks that specific square.

There seems to be a lot of calculations needed to do this but let me try if it isn't as expensive in my engine.

[hgm]

Has anyone done more studies of
attack-map always-on vs. only-when-needed?

I plan to test an implementation that always keeps attack maps only for occupied squares. The porpose is to make MVV/LVA move generation in QS trivial, especially detecting the case where you have no captures. I also want to use it to lower the eval score in cases there exist multiple LxH captures or any x undefended captures against the stm, by the value of the second-most important such threat.

I will report on this soon (I hope).

[MDiaz]

Yow only need too update alf of the board (black pieces or white pieces) before gen moves. If yow use for eval mobility fe. yow ned to update the other half too...