hashtable

I don't have experience with hash tables outside of arrays/dictionaries in dynamic languages, so I recently found out that internally they're implemented by making a hash of the key and using that to store the value. What I don't understand is why aren't the values stored with the key (string, number, whatever) as the, well, key, instead of making a hash of it and storing that. BobMcGee This is a near duplicate: Why do we use a hashcode in a hashtable instead of an index? Long story short, you can check if a key is already stored VERY quickly, and equally rapidly store a new mapping. Otherwise

Here's a description of the data structure: It operates like a regular map with get , put , and remove methods, but has a sort method that can be called to sorts the map. However, the map remembers its sorted structure, so subsequent calls to sort can be much quicker (if the structure doesn't change too much between calls to sort ). For example: I call the put method 1,000,000 times. I call the sort method. I call the put method 100 more times. I call the sort method. The second time I call the sort method should be a much quicker operation, as the map's structure hasn't changed much. Note

So, I am looking at different hash functions to use for hashing a 4 tuple ip and port to identify flows. One I came across was ((size_t)(key.src.s_addr) * 59) ^ ((size_t)(key.dst.s_addr)) ^ ((size_t)(key.sport) << 16) ^ ((size_t)(key.dport)) ^ ((size_t)(key.proto)); Now for the life of me, I cannot explain the prime used (59). why not 31, and then why go mess it up by multiplying the sport by a power of 2. Is there a better hash function to be used for ip addresses ? The prime number is used because when one value is multiplied by a prime number it tends to have a higher probability of

I need to know if a ternary tree is better than a hash table . I came across this question in a reply to another question I had where someone said that ternary trees are often faster than hash tables. I found that hard to believe, so I decided to research a little into it. This one website from Princeton appears to be the source of the belief. I took a look at algorithm which is described to be O(log n + k) where n is the number of words stored, and k is the length of the key. It seems to me that the only way this could be faster is if you are often searching for elements that are not already