PLS correct me if i misunderstood sth.
LITLLE SUMMARY MAGIC-MGEN (just for me
):==============================================
main advantages:
- simultaneously generating 4 directions
- quick access to precomputed tables containing the moves(attacksets),
by using hashfunction like "(MAGIC * OCC)>>(64-bts)"
main disadvantage:
- great lookup-tables (especially for rooks).
IDEA:
=========
Like it is usual in other bitboard approaches to split the directions for movegeneration,
it also can be done in the "magic-approach".
Of course the gain of simultaneously generating all directions will be lost.
But on the other hand the magic tables would shrink enormous.
(i think in comparison to other bitboard-move-generation schemes, eg. rotated bitboards,
there may be also saved a lot of work.(here for instance rotating the bb. i hope you
know what i mean. i am not experienced in the most other bb-schemes.)
At the end, one could make the compromise, not to split all directions.
example: create magics for R(NN and SS),B(NW and SE), or any other combination.
a magic-shift-set for the 2 examples can look like this...
========
=....h8=
=a1....=
========
F(): (MAGIC*OCC)>>(64-BTS)
FOLLOWING (SOME) "BTS"-Numbers
ROOK: NN and SS
6 6 6 6 6 6 6 6
5 5 5 5 5 5 5 5
5 5 5 5 5 5 5 5
5 5 5 5 5 5 5 5
5 5 5 5 5 5 5 5
5 5 5 5 5 5 5 5
5 5 5 5 5 5 5 5
6 6 6 6 6 6 6 6 ENTRIES: 2560 SIZE: 20480 byte
BISHOP: NW and SE
6 4 4 3 2 1 1 1
5 5 4 3 2 1 1 1
4 4 5 4 3 2 1 1
3 3 4 5 4 3 2 2
2 2 3 4 6 4 3 3
1 1 2 3 4 5 3 4
1 1 1 2 3 4 4 4
1 1 1 2 3 4 4 5 ENTRIES: 768 SIZE: 6144 byte
OR SINGLE SPLITTED...
ROOK: NN only
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
2 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4
5 5 5 5 5 5 5 5
7 6 6 6 6 6 6 6 ENTRIES: 1106 SIZE: 8848 byte
BISHOP: SW only
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 2 2 2 2 2
1 1 1 2 3 3 3 3
1 1 1 2 3 4 4 4
1 1 1 2 3 4 5 5
1 1 1 2 3 4 4 6 ENTRIES: 394 SIZE: 3152 byte
So what do you think? does it make sense to split the magics, to get the small tables
or will there be a dramatic speed lost due to generate the "splitted" directions?
Also i would be interested in the dimension of how the uncompressed magic-tables influence the speed. (i used magic-bb until now only with absolut uncompressed tables 4096,512(r,b) index). But anyway it seemed they are working very fast...