hashtable

Which is faster to find an item in a hashtable or in a sorted list? yves Baumes Algorithm complexity is a good thing to know, and hashtables are known to be O(1) while a sorted vector (in your case I guess it is better to use a sorted array than a list) will provide O(log n) access time. But you should know that complexity notation gives you the access time for N going to the infinite. That means that if you know that your data will keep growing , complexity notation gives you some hint on the algorithm to chose. When you know that your data will keep a rather low length: for instance having

HashTables/HashMaps are one of the most (if not the most) useful of data-structures in existence. As such, one of the first things I investigated when starting to learn programming in Cocoa was how to create, populate, and read data from a hashtable. To my surprise: all the documentation I've been reading on Cocoa/Objective-C programming doesn't seem to explain this much at all. As a Java developer that uses "java.util" as if it were a bodily function: I am utterly baffled by this. So, if someone could provide me with a primer for creating, populating, and reading the contents of a hashtable:

Apparently, you cannot use a null for a key, even if your key is a nullable type. This code: var nullableBoolLabels = new System.Collections.Generic.Dictionary<bool?, string> { { true, "Yes" }, { false, "No" }, { null, "(n/a)" } }; ...results in this exception: Value cannot be null. Parameter name: key Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. [ArgumentNullException: Value cannot be null. Parameter name: key] System.ThrowHelper

What is the best way to remove an entry from a hashtable that uses linear probing? One way to do this would be to use a flag to indicate deleted elements? Are there any ways better than this? An easy technique is to: Find and remove the desired element Go to the next bucket If the bucket is empty, quit If the bucket is full, delete the element in that bucket and re-add it to the hash table using the normal means. The item must be removed before re-adding, because it is likely that the item could be added back into its original spot. Repeat step 2. This technique keeps your table tidy at the

I need to create a dictionary/hashmap where the Keys are enums Values are some subclass of NSObject NSDictionary won't work here (enums don't conform to NSCopying ). I could perhaps use a CFDictionaryRef here, but I'd like to know if is there any other way to achieve this. Since enums are integers, you can wrap the enum in an NSNumber. When you add/retreive something to/from the map, you pass the enum to the NSNumber constructor... Assuming you've got an enum like... enum ETest { FOO, BAR }; You can use it in an NSDictionary like this... NSMutableDictionary *dict = [[NSMutableDictionary alloc]

On CLRS's textbook "Introduction to Algorithm", there's such paragraph on pg. 258. We can delete an element in O(1) time if the lists are doubly linked. (Note that CHAINED-HASH-DELETE takes as input an element x and not its key k, so that we don't have to search for x first. If the hash table supports deletion, then its linked list should be doubly linked so that we can delete an item quickly. If the lists were only singly linked, then to delete element x, we would first have to find x in the list so that we could update the next attribute of x's predecessor. With singly linked lists, both

I recently learned about different methods to deal with collisions in hash tables. And saw that the separate chaining with linked lists is always more time efficient, and for space efficiency we allocate a predefined memory for Linear probing which later on we might not use,for separate chaining we utilize memory dynamically, so is separate chaining with linked list not more efficient than Linear probing?if yes why do we then use Linear probing at all? I'm surprised that you saw chained hashing to be faster than linear probing - in practice, linear probing is typically significantly faster

I'm trying to write a C program that uses a hash table to store different words and I could use some help. Firstly, I create a hash table with the size of a prime number which is closest to the number of the words I have to store, and then I use a hash function to find an address for each word. I started with the simplest function, adding the letters together, which ended up with 88% collision. Then I started experimenting with the function and found out that whatever I change it to, the collisions don't get lower than 35%. Right now I'm using unsigned int stringToHash(char *word, unsigned int

In cases where I have a key for each element and I don't know the index of the element into an array, hashtables perform better than arrays (O(1) vs O(n)). Why is that? I mean: I have a key, I hash it.. I have the hash.. shouldn't the algorithm compare this hash against every element's hash? I think there's some trick behind the memory disposition, isn't it? bitfox In cases where I have a key for each element and I don't know the index of the element into an array, hashtables perform better than arrays (O(1) vs O(n)). The hash table search performs O(1) in the average case. In the worst case,