Gerd Isenberg wrote:Congrats! What squares were the most difficult one to find? Edges or border - near 0,7,56 or 63?
The worst squares seems to be the edges.
About hash collisions, I already accept those if they give the same pattern.
About the addressing; on square A1 I have to 'see' A2-A7 and B1-G1 = 12 bits, giving 4096 different addresses. But, on A1 there is atmost 7*7=49 different patterns to lookup, and, if I have enough 'good' collisions (around 2000 or more), it would be teoretically possible to find a key that map those 49 patterns to 2048 elements. Time will tell. It's easier for squares inside B2-B7-G7-G2, because one have only 2*5=10 bits giving 1024 different addresses (8 minus edges minus piece). For D4,E4,D5,E5 one have 12*12=144 different patterns to lookup. It seems like the number of addresses is the heaviest part to deal with.
Pradu wrote:Mabe it isn't possible to find the keys needed in RmovesIncrement in reasonable time using a brute force method considering the trouble you had generating keys for a 1 to 1 minimal perfect hash (the 4906 one)...does anyone know of more efficient ways to find these keys or to find out if such keys even exist?
I do not have a minimal perfect hash, and I dont think I can make it either. When I found keys to map 4096 addresses to max 144 patterns many of them are probably 'good' collisions.