From 4458c8e3fd7b5afeab6311609e2c5924c75d144c Mon Sep 17 00:00:00 2001 From: anebz Date: Fri, 5 Apr 2019 23:52:11 +0200 Subject: [PATCH] chapter 1 hash table collision explanation from chapter 11, exercise from chapter 7 --- Chapter 11 Advanced topics/README.md | 23 ++++++++++ .../7.12. hash_table.md | 43 +++++++++++++++++++ Chapter 7 Object-Oriented design/README.md | 5 +++ 3 files changed, 71 insertions(+) create mode 100644 Chapter 11 Advanced topics/README.md create mode 100644 Chapter 7 Object-Oriented design/7.12. hash_table.md create mode 100644 Chapter 7 Object-Oriented design/README.md diff --git a/Chapter 11 Advanced topics/README.md b/Chapter 11 Advanced topics/README.md new file mode 100644 index 0000000..dd5fb53 --- /dev/null +++ b/Chapter 11 Advanced topics/README.md @@ -0,0 +1,23 @@ +# Chapter 11 Advanced topics + +## 11.4. Hash table collision resolution + +Collision in a hash table means there's already an item stored at the designated index. + +### 11.4.1. Chaining with linked lists + +The hash table's array maps to a linked list of items, items are just added to the linked list. As long as the number of collisions is fairly small, this is quite efficient. In the worst case, runtime is O(n), where n = \# elements in the hash table. This would only happen with strange data or a very poor hash function, or both. + +### 11.4.2. Chaining with binary search trees + +Rather than storing collisions in a linked list, store them in a binary search tree. The worst case runtime is then O(logn). This approach isn't used unless we expect a very nonuniform distribution. + +### 11.4.3. Open addressing with linear probing + +When a collision occurs, we move on to the next index in the array until we find an open spot, or sometime, some other fixed distance, such as idx + 5. If the \# collisions is low, this is very fast and space-efficient. A drawback is that the total \# entries in the hash table is limited by the size of the array, which isn't the case with chaining. + +Another issue called *clustering*, a hash table with an underlying array of size 100, where only indexes 20-29 are filled. The odds of the next insertion going to index 30 is 10%, since any item mapped to 20-30 will end up at index = 30. + +### 11.4.4. Quadratic probing and double hashing + +The distance between probes doesn't have to be linear, it can be quadratic, or use another hash function to determine the probe distance. \ No newline at end of file diff --git a/Chapter 7 Object-Oriented design/7.12. hash_table.md b/Chapter 7 Object-Oriented design/7.12. hash_table.md new file mode 100644 index 0000000..ee56e52 --- /dev/null +++ b/Chapter 7 Object-Oriented design/7.12. hash_table.md @@ -0,0 +1,43 @@ +# Hash table + +## Design and implement a hash table which uses chaining (linked lists) to handle collissions + +## Non-OOP solution + +```python +hash_num = 10 +def hash_table(vals): + items = [] * hash_num + for v in vals: + mod = v % hash_num + if items[mod]: + items[mod].append(v) + continue + items[mod] = [v] + return items +``` + +## OOP solution + +```python +class hashTable: + + def __init__(self, hash_num=10): + self.items = [] + self.hash_num = hash_num + + def create_hashtable(self, vals): + items = [[] * hash_num] + for v in vals: + items[v % hash_num].append(v) + return items + +def main(): + vals = [1,3,4,5,10,11,13,14] + hasht = hashTable() + items = hasht.create_hashtable(vals) + print(items) + +if __name__ == "__main__": + main() +``` \ No newline at end of file diff --git a/Chapter 7 Object-Oriented design/README.md b/Chapter 7 Object-Oriented design/README.md new file mode 100644 index 0000000..52bd1ad --- /dev/null +++ b/Chapter 7 Object-Oriented design/README.md @@ -0,0 +1,5 @@ +# Chapter 7 Object oriented design + +## Resouces + +* [C++ solutions](https://github.com/careercup/CtCI-6th-Edition/tree/master/Java/Ch%2007.%20Object-Oriented%20Design) \ No newline at end of file