What is the best way to create AttackTable in mailbox or 0x88 board representation.

[hgm]

Yeah well that is all assuming a very simple evaluation function.
Much better is to do the capture, carry it out, and have the next position do a full evaluation and return the value above beta there if that's the case.
There could be a king safety issue in place, or a apassed pawn that you captured, or a piece hung in the corner that suddenly no more is hung.
Better capture those pieces and see what evaluation is after it than to use futility pruning there.

If this simple method (futility pruning) works well for you - no hope to beat the ANN engines of course - you need to show up with a bit more sophisticated evaluation function to beat them.

That depends on what the maximum score is that can be associated with these king-safety or passer terms, and which margin you use. If the margin is large enough (i.e. larger than the maximum value of all non-evaluated terms together) futility pruning is mathematically sound, and doing the full evaluation would just be a waste of time. The problem of course can be that the margin has to be very large, if you have a 'wild' evaluation, so that in practice you don't prune very much.

Most engines therefore use the margin as a tunable parameter, and use the value that results in the highest Elo. Even if that is a value that theoretically is not sound, and prunes nodes that would have failed high on exact evaluation. This makes sense; the fraction of stand-pat nodes is usually larger than 50%, so you can potentially save a lot of work by skipping those evaluations. Especially when you have a complex evaluation that dominates execution time. Spending this time just to catch the rare cases where an unusually large eval swing could cost you one ply of search depth. It usually pays to focus the effort on nodes that have the largest chance of making a difference, and nodes that superficially fall very far short of alpha are very unlikely to make up the deficit.

Besides, if some large terms are reasonably likely to contribute, there often are tricks to account for that. E.g. the case of the passers: you could exclude moves by a Pawn or captures of a Pawn from pruning, so you would not inadvertantly prune moves that create a passer.

Most engines even use a similar kind of pruning at d=2 and d=3, which is completely 'unsound': no matter how large the margin, you could lose a King in the remaining 3 ply. But hey, if it increases Elo...

[Rein Halbersma]

Most engines even use a similar kind of pruning at d=2 and d=3, which is completely 'unsound': no matter how large the margin, you could lose a King in the remaining 3 ply. But hey, if it increases Elo...

I guess it's conceptually not more 'unsound' than using a heuristic eval in the first place.

[hgm]

Well, 'unsound' in this context is usually taken to mean that the pruning can alter the score of the node. Whether the altered score was any good in the first place is another (but of course not unimportant) issue.

[Rein Halbersma]

Well, 'unsound' in this context is usually taken to mean that the pruning can alter the score of the node. Whether the altered score was any good in the first place is another (but of course not unimportant) issue.

Agreed. I meant: standing pat and calling eval() can also alter the score wrt searching until the end of the game / tablebases. In heuristic search it's all about playing the percentages and guiding the program to the most relevant nodes. Pruning bad positions near the leafs is just one of the manifestations of this philosophy.

[diep]

Well, 'unsound' in this context is usually taken to mean that the pruning can alter the score of the node. Whether the altered score was any good in the first place is another (but of course not unimportant) issue.

REality is that the perfect tuning as achieved by 2005 by certain engines is in fact a pretty agressive tuning. Now diep is only hand tuned. In 2009 i did do tunings experiments at 80 cores thanks to Renze Steenhuisen who did much work there for me carrying out the experiments. After each 'bugfix' basically the entire tunings run had to get redone.

Basically king safety no bugs got out there, seemed i had pretty much fixed that, even though that can get like 40 pawns penalty or more.

diep has king safety code which scans whether pieces cooperate against your kingsafety - that can already get some pawns of attackbonus, works very very well. First time introduced (but still a tad buggy) was in 2004. Directly won me a few points. Against Fritz and against whatever Uri Blass played with. in later years that code was bugfixed significantly.

A critical thing is detecing also how closed/opened position is then.

I turned off that code - bugfixing that part appears really difficult as it requires a lot of additional knowledge on where closed positions can get opened potentially which would be massive work not to mention bugfixing it first.

It is difficult based upon metaknowledge to reevaluate penalties/bonuses yet if it works after fixing patterns well it is really effective. Basically of course a simple but very effective example how this gets done was reintroduced by Fruit, which averages between 2 different piece square tables based upon a simple count of the material left on the board. Taken over by most engines nowadays. Diep had there already a more sophisticated discrimination. The initial material score delivers 256 phases which gets splitup into 16 phases for each side. Introduced in 2000.

That proves to be really effective.

Interestingly i introduced 1 major bug in the material evaluation which i didn't find until short after world champs 2005.

When that had been fixed that gave really a +300 elo boost in elo for diep back then. Was really shocked.

If you do that with other terms that can give far more bonus of course your evaluation needs to be fixed pretty well. The parameter tuning experiments basically removed a couple of major bugs from passed pawn code back in 2009.

After each run which took quite some computation work it showed up with basically lots of bugs yet basically the same 'buggy' pattern delivers then dozens of problems. So you need to fixe that first - redo the entire run and fix next issue. Never got to that. Lack of computational power back then. Not enough cores.

Yet once reasonable bugfixed such evaluation is really powerful. Wins everything.
Yet bugs really need to be removed fully.

It leads to very agressive tuning - any form of lazy forward pruning doesn't work at all anymore.

The basic reason why it 'seems' to work for most engines is because it also improves move ordering deeper in the tree. Becasue in stead of a cutoff by nullmove which gives a value close to beta and basically messes up your move ordering when backtracking it, you do a hard cutoff here which is further away from beta usually. Improves move ordering in short.

That's what confuses most people in saying hard forward pruning works near the leaves very well

Better is to be less selective near the leaves and more selective (not pruning but reduction factors) closer to root . Any form of dubious overruling your evaluation is a no no.