Boost logo

Boost :

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

"Topher Cooper" <topher_at_[hidden]> wrote in message
| 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,
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
that a different type could have a similar hash index?



Boost list run by bdawes at, gregod at, cpdaniel at, john at