"Topher Cooper" <topher@topherc.net> wrote in message news:5d405343dda154b3e8190cf9087b52a1@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