just curious, why are the full hashes not compared when least significant octets match (above)?
On Thursday, July 16, 2015 at 12:25:01 PM UTC-4, Matt Bauman wrote: > > On Thursday, July 16, 2015 at 12:19:25 PM UTC-4, milktrader wrote: >> >> Also, back to the OP question, is the correct solution to simply define >> >> Base.hash(f::Foo) = f.x >> > > No, I'd define Base.hash(f::Foo) = hash(f.x, 0x64c74221932dea5b), where I > chose the constant by rand(UInt). This way it won't collide with other > types. I really need to spend a bit more time with my interfaces chapter > and add this info there. > > On Thursday, July 16, 2015 at 12:07:50 PM UTC-4, Seth wrote: > >> If I'm reading between the lines correctly, the default/existing hash >> function is based on the last byte of the ID? Is there a reason we don't >> make the table wider to reduce the chances of collisions (or would this >> have bad effects on memory utilization)? >> > > It's not really a hash collision, but rather a hashtable index collision. > A new dict only has 16 slots for its keys, and the index for an element is > simply chosen by the last 8 bits of its hash. If those last 8 bits match > the hash of an object already in the table, there's a collision, and the > Dict checks to see if the existing element `isequal` to the new one (and > doesn't look at the hash again). So the hashes are different, but isequal > says the objects are the same. This is why things are wonky. >
