Hi Geoff,
I have written one program with attack tables (Gothmog) and one without (Glaurung). I'll try to answer your some of your questions below.
GeoffW wrote:Hi
I have been reading Ed Schr?ders page regarding calculating attack tables. I have coded up a version quite similar to that described by Ed. To test it and get it working I have currently just called the white & black table generation in my Eval function just after the lazy eval decision.
This is similar to what I do in Gothmog, except that I have never used any kind of lazy eval.
This allowed me to use it for a hopefully improved king safety calculation.
If you end up finding attack tables useful for king safety and little else, you may want to have a look at the king safety evaluation in Glaurung. It is somewhat similar to Rebel's king safety, but does not use attack tables.
It wasnt a total surprise to find that it is very expensive on my nodes per second to generate this information. To make proper use of the time spent calculating the tables I really need to use it for more than just king safety. This is where I get a bit hazy and could use some advice please
Attack tables could be further used for
1) More Eval functions, eg Center control etc. The table generation can be left where it currently is for this addition
Yes, the evaluation function is by far the most important use of attack tables. If you don't find several good uses for attack tables here, they are not worth the price. Besides king safety, I have found attack tables to be particularly useful when evaluating space and mobility. In the space eval, you can do a table lookup to check whether a square is controlled by white, controlled by black, or neutral. In the mobility eval, attack tables can be used to compute safe mobility (pseudo-legal moves which do not lose material) almost as cheaply as plain mobility.
2) Fast in check and and checking move calculations. To make this work however I need to move the table generation earlier to maybe after the makemove function. This would cause more of a slowdown in nps
This point has very little importance. In check and checking move calculations can be done with almost zero cost, even without attack tables. You do this by looking at the last move made (or the move you are just about to make). For most moves, looking at the 'from' and 'to' squares is sufficient to see that the move cannot possibly be a check. For the remaining moves, it is only necessary to scan for attacks in one (or occasionally two) directions. Look at attacks.c in Glaurung if you want an example of how the code could look.
3) Further work could make the tables give a SEE feature, used for move ordering. The big snag with this is that table generation would have to be done for all moves at move generation. This means that we move the generation before any beta cutoffs and would cause a crushing slowdown in nps. If I moved this code into the move gen function I think I would need to measure speed in seconds per node
I wonder if Rebel does the attack table gen at move generation time, I am assuming it must do ?
Of course I have never seen Rebel's code, but I always assumed that it did attack table generation during or directly before evaluation (just like I do in Gothmog). I don't see any point at all in doing attack table generation at move generation time.
One more possible use of attack tables which you didn't mention:
4) Static mate detection. Many common mating patterns can be detected by using attack tables. For instance, if the black king is on g8, the g7 square is attacked by the white queen and at least one other white piece, and no black piece except the king defends g7, we can be almost sure that Qxg7 is a mate in one. Note that we cannot be 100% sure: The white queen could be pinned, or there could be an X-ray defence by a black piece through the white queen. It is therefore not safe to return a mate score. Nevertheless, this kind of static mate detection can be useful. You can use it in move ordering, by placing the move which is almost certainly a mate in one first in the move list. In the qsearch, you can decide to search the (probably) mating move even if you don't normally search all checks.
Tord
At any rate, Kiwi has been able to use attack tables for several versions now and in my experiments I have found results quite similar to yours. However, in my case the version with attack table although much slower was just slightly worse than the version without, but usually considerably better against other engines.
