You were laughing towards me. Even you posted a 'smile'.
As for a few minutes you thought you could beat the combination of
rotation with addition with just addition.
I am still smiling. Really there is no point to do additional rotations when you have two good thoroughly randomized hash keys in [piece] and [square]. It beats anything else because it requires one simple operation given those tables.
You suggested a rotation method while using tables..what is the point in that? It sure is going to be dog slow compared to simple addition.
Don acked you in that.
Also explicitly mentions only addition.
That's 2 of you.
Fact is what i posted is about a 5x faster than what you showed up with.
You don't get what is being said. Like I said addition is the simplest there is given two tables. You _also_ use tables so the rotations are unnecessary.
Even the method I suggested later that produces the keys from scratch is different from yours. RanRot does two fixed rotations of 5 and 3, so it automatically means use of tables. But if you just rotate by 1 bit for each square (upto 64), you can avoid table lookups...
p.s. it's good habit to remove the 'you are so dumb' you initially posted.
We xor for the normal zobrist function but addition for computing a key to use for a color/piece/square combination. At least that is what someone in an early post recommends and claims is strong. I cannot vouch for that but it could very well be good.
HG uses addition for all his engines instead of the xoring zobrist hash so mixing add and xor should be stronger than that. Infact I use addition for holdings in crazy house to get a separate key for holdings. Then later when xored with the main hash key, it becomes exactly like what I suggested here for piece_square combinations too. So those are some strong suggestions that it works fine in practise.
To me using addition is the best practical solution for combining the 2 small random tables. All the rest was just an intellectual exercise. It would be one of those things one might do if they had a lot of ROM but only a little RAM in a small embedded device - but then you probably would not have hash tables anyway. But you still might want keys for repetition detection. And there was the hope that some sort of local hashing here would be faster - but that's just hope as it appears that to produce reasonable randomness without any tables requires a fairly sophisticated hash function.
Daniel Shawul wrote:
It was me who suggest that a combination using multiplication would work, yet would be too slow.
No. You haven't even started posting by that time (fact!). I suggested addition over multiplication after doing some bit frequency tests. Go ahead check the post on the first page. Actually addition has two fold advantages as that also keeps the uniform distribution.
Throughput latency, we aren't even looking to total latency, of multiplication is 3.75 clocks at intel cpu's.
Therefore the proposal to use what RanRot is using to generate random numbers, namely a combination of 2 rotations with 1 addition, that's a lot faster than doing a multiplication.
Accusing me of trolling is not a good habit.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
