Magic Move generation

[Pradu]

That would make things even worse -- huge arrays of numbers which look meaningless to the reader is exactly what I want to avoid.

Document how to generate it then.

The source code should be self-documenting, and not contain a bunch of magic numbers which do not make sense without a long explanation.

The explanation is simple, try random numbers until one works. The actual hash function is what will probably take the largest amount of text to document and you will have to document this anyways.

Writing magic generation code at startup seems like an overkill workaround for not having to explicitly document code. The tables arn't that large anyways, just arrays of 64 and you can use higher quality magics if you pregenerate them.

[Gerd Isenberg]

Thanks for all suggestions, everyone!

or to format the magics with leading zeros, four in a line.

I don't understand this one.

Only an esthetic remark on printing the magics with 16 hex-digits each, for better "table" alignment or concision.

Code: Select all

not
 0x440049104032280ULL,  ...
 0x48c4440084048090ULL, ...
but
 0x0440049104032280ULL,  ...
 0x48c4440084048090ULL, ...
e.g. with
printf("0x%016I64XULL\n", magic);

If you incorporate the shift the most significant nibble is unequal zero anyway.

[Pradu]

I think what I need to do is to find an efficient, clear and readable algorithm for computing all the magic numbers during startup, which does not involve trying random numbers until I find some that work.

This should be possible if you only intend on generating magics where the number of bits in the index is equal to the number of bits possible in the occupancy. Perhaps you could try something like: for each bit in the index and each bit in the occupancy, 'or' indexbit/occupancybit into the magic which initially starts at zero. This ignores some side-effects from other occupancy bits, but it probably might still work.

[wgarvin]

I think what I need to do is to find an efficient, clear and readable algorithm for computing all the magic numbers during startup, which does not involve trying random numbers until I find some that work.

I understand Tord's desire to have clean and understandable code, with no unnecessary nasty-looking stuff in it. However, in this case I suggest that the benefits of the magics are worth having a little nastiness, and the difficulty of finding optimized magics makes it worth having the pre-initialized arrays.

So my suggestion is: Keep all the nasty stuff together in one file, and separated from everything else. It should have a simple and clean interface (inlined accessors or whatever) to the rest of the engine. The rest of the engine does not have to know it even exists.

Sometimes its worth it to have some ugly code. The trick is to keep that ugliness safely contained in one place and not let it infect the rest of your codebase.

[Edit: also, sometimes the use of macros can make the code slightly cleaner. For example: if your pre-initialized 64-bit values were actually the combination of a magic number and a 6-bit shift value, you could make this explicit by writing the table entries as MAGIC(0x123456789ABCDEF0, 25) or something like that.]

[jwes]

[snip]
Moving them from the source code to a separate text or binary file and reading them at startup, as Wesley suggests, doesn't really make any difference.
Tord

The difference is that the program has the code to generate the numbers, rather than the numbers, which is what I thought you wanted. The binary file is only a timesaver, so you don't have to wait minutes (or hours, or days) each time on startup.