[boost] Re: [review] hash functions

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-13 14:10:08

"Topher Cooper" <topher_at_[hidden]> wrote in message 
news:5d405343dda154b3e8190cf9087b52a1_at_topherc.net...
|
| On Mar 13, 2005, at 11:13 AM, Peter Dimov wrote:
| > implementation to which you port your program. Your original tests are
| > still valid.
| >
| > The other side of predictability - that the hash function is not
| > affected by types or the particular representation of a sequence of
| > values - means that you don't necessarily have to re-run the
| > performance benchmark of your unordered_maps when you refactor the key
| > to use int[3] instead of struct { short, short, short }, or a wstring
| > instead of a string.
| >
|
| Fundamentally, what makes for a good hash function is that things that
| are equal (however you are defining equality) always hash to the same
| value, while any small difference between two things should cause them
| to hash to completely different values.  In an arbitrary program would
| I expect an int[3] to be equal to a struct { short, short, short } when
| the values happened to be equal?  No.  What if the change in
| representation you spoke of was to rotate the coordinate axes for my
| vector, would I expect values with the same coordinates in the two
| different coordinate-systems, represented by different structs to be
| equal?  No.  If I have two structs representing complex numbers, one
| using a Cartesian representation and the other polar would I expect
| them to be treated as equal because their coordinates are equal?  No -- 
| I would be appalled if they were.

can you point to any examples where this is a problem in real code? I mean, 
the
hashing is all about looking up some element, as long as I get it, then what 
do I care
how its gotten?

In particular, we mostly have a container of *one* type, so what does it 
matter
that a different type could have a similar hash index?

br

-Thorten