grant wrote:Edmund
I may have mis-understood your terminology.
I measure the potential of finding a magic number by counting the first n number of occupancies that I can fit into half this number.
So for B7 I get the first 527 of 1024 to fit into 512
for G2 I get 992 of 1024 into 512
for A1 I get 3500+ of 4096 into 2048
Based on my results so far, G2 and H2 are very good candidates for searching.
Grant
I did it row by row:
for example sq#9:
First I start where the file has no pieces and try to fit the 6 possible occupancies from the row into as little index numbers as possible (the occupancies are all subsets of 0x7c00). For this I found that the lowest possible index number usage was 14 and the bit-pattern that all the magic numbers had in common was: xxxxxxxx xxxxx011 11111111 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx.b
Then I continued with the subsets of the occupancy 0x2000000007c00. I was using the bit-pattern gained from the previous step. The lowest number of indexes used here was 34. Here again I got a pattern I used for the next steps.
For the occupancy 0x2020000007c00 I got the minimum of 68 indexes, for 0x2020200007c00 136 indexes and for 0x2020202007c00 280. For the last step (0x2020202027c00) I didn't find anymore magics, probably due to the fact that the number of indexes used > 2^9
I now concluded that it was close, because I saw a development of the indexes used about at the rate of 17*2^[nr of file-occupancy bits]
Edit: and 17*2^5=544 is close to 2^9
Another idea: in the case we weren't able to find a bit-reduction for a certain square, we should still try to find a magic number that reduces the highest index number used, as this would still be a good improvement.
Edmund