On 12/08/16 16:37, Ellison Anne Williams wrote: > Thought that I responded to this -- oops - sorry! > > As hashes can be (naturally) negative, taking the absolute value avoid twos > complement issues when we are only taking certain bits of the hash (instead > of the whole thing). I would have to go back through to see if we could > alleviate these issues in another way - it's possible (as I recall, this > was a quick fix).
Not sure that I understand that, as the code is dependent upon the return value of String#hashCode (i.e. it is an 'unknown' 32-bit value). You are just as likely to get a hash collision by 'folding' the hash value range using abs() as you are taking the lower bits and ignoring the sign bit, aren't you? Regards, Tim > On Fri, Aug 12, 2016 at 11:06 AM, Tim Ellison <[email protected]> wrote: > >> Anyone got thoughts on this? >> >> On 10/08/16 17:23, Tim Ellison wrote: >>> Why does >>> org.apache.pirk.utils.KeyedHash#hash(String key, int bitSize, String >>> input) >>> >>> have >>> int fullHash = Math.abs(concat.hashCode()); >>> >>> What is the value of performing the "Math.abs" in computing this hash? >>> >>> p.s. I now realize I'm entering the toddler phase of Pirk development, >>> where I wander around constantly asking "why?" :-) >>> >>> Regards, >>> Tim >>> >> >
