Hash Tables, Associative Arrays, and Dictionaries (Data Structures and Optimization) 

I found the nihilistic voice tone a perfect match to learn IT stuff.

These were 13 relaxing minutes of listening to you talk about hash tables (Y), enjoyed, thanks!

Probably also worth mentioning the case of *no* collision resolution, and just doing an unconditional overwrite, basically a "lossy hash table", which gives guaranteed constant-time lookups. This approach is commonly used in chess engines, where it's used to cache position evaluations to spare the search from having to recurse further down the game tree. Of course, collisions happen and you lose the evaluation previously held in that slot, but that just means you have to search the position, which you'd have to do anyway if you weren't using the hash table to begin with, so it's a huge win overall.

9:19 that's why small objects in javascript (v8) are internally represented as two arrays, one for the keys and another for the values instead of a hash tables

Although being a motion designer by trade, I have a strong interest in programming and data analysis. After discovering your channel a few days ago, I have been binge watching. I’m one third done with your shaders course. Learning from you is like shopping at Home Depot for my graphics/programming self improvements. Sarcasm is the icing on the cake! Thanks Simon.

The timing of this video couldn't be more perfect, Just had a class lesson about hash tables today!

I am addicted to this channel. your way of explaining stuff really kills it.

This is very nit-pikcy but "Hermes" is most definitely 6 letters Great video haha

Thank you for all your videos!! As someone who is in its early university years and has a job a software developer, I can learn a lot with all of your content! Again, thank you so much and great work!

Please support future vids: www.patreon.com/simondevyt

The energetic funny text makes for a good contrast with the calm, almost sleepy voice. I don't know when I might need to handcraft an artisanal data structure but this is neat!

This video was beautiful and very relevant to a discussion I was having recently about how Big O notation is often misused and can be misleading, because people try to optimize for handling numbers of items they won't ever be handling.

Okay so I've literally never understood these damned things before, mainly because I'd never been able to get over how they're different than arrays, and you just cleared up months worth of confusion in a few minutes. You're my new favorite.

new vid by the king! I can't wait until this series reaches the wierdest types of trees. I guess sometimes it is best to keep it simple, but I am really pumped to hear some stories about custom datatypes you've seen in your life. useage, flaws, or brilliant solutions by you or your coworkers. I bet youve encountered some.

thank you for using those names it made my day

Great explanations with slang sauce. They make hard chunks of information tender and more digest. Bravo

Great video as always Simon, keep them coming, it's a privilege to learn from you

This channel is my best discovery in 2022

Even as an experienced developer, i find your videos are very entertaining and informative. 😘

RU-vid algorithm -> awesome channel. Profit!!

Great stuff man, knew it from my studies but great refresher on the basics. Subed!.

Great video as always. The animations were fun, please keep them in future videos too.

Just discovered your channel and totally charmed, great, funny, clear and instructive. la la la, I can see this

Informative and entertaining. How I handled it with one of my earliest attempts at implementing hash tables was to store the non-normalized key with the data, I had an array of all the data as a power of two so lookups were by key&(p2-1) and I had an array of dynamic arrays for the buckets storing an index into the main array of data. For deletions I would swap the element to be deleted to the end of the array and repoint the element that was there to the place where the old element was and decrement. Since each bucket array merely stored an index into the main data array when I resized or sorted, I could just rebuild the bucket arrays using the stored hash and not have to query the hashing function. On my old 533mhz celery it could handle millions of strings quite fast. So I've been iterating many designs for hash tables since.

Beautiful presentation

Great compilation, thank you. 👍

Very good videos. Great presentation. Thanks!

I wrote a puppeteer script to like all your youtube videos. Next goal: Using a corn-job to check for new videos and like it as soon as they come.

the peppering of dry sarcasm is everything ive ever wanted in programming info videos. You have a new dedicated viewer. Now I just need to find a sweary programming channel.

Thks. I envy your computer expertise & your fluency in teenager speak.

saw Futurama references and immediately subscribed

Excellent video!

That. Was. Beautiful.

I love this freaking videos

3:10 nearly choked on my coffee there.

my mind was absolutely blown when I learned about hash tables in m data structures class in 2015/6. They're still my favorite data structure (yes, im weird. i have a favorite data structure lol)

Simon, your javascript contents are golden, please make more of thses! Also your Making game videos are entertaining!

Couldn't resist clicking on the Cuckoo Hashing couldn't you Simon? XD

Now, that sounds like some wise old man giving me essential life lessons 😂😂. Thanks a lot though... ❤️

That was awesome 😎😎😎😎😎

"pedantic != skilled" hahahahahah ❤

"holding a bunch of crap" hahahaha 🤣

Im trying to implement your spatial hash grids to form a good basis for calculating road network connections in a tile based system, getting there with it but wonder if you have thought of doing a video on it? Love the content btw!

Love your videos! Could you do one discussing design patterns?

If anyone enjoyed this video, I would highly recommend looking up Raymond Hettinger's talk on how new dictionaries are implemented in Python. It's a fantastic distillation of many topics such as learning from history, software project politics, and (of course) data algorithms.

I love thinking about data structures. I hope I don't get crucified for this, but one thing that I found myself adding is a sort-of Frankenstein's monster between arrays and linked lists, in the form of a linked list that stores an array in each node. An example of a use case: I work in game development and the framework that I use specializes in parallel processing. But having multiple threads write to the same output without taking proper precautions is a recipe for disaster. An array-backed list could be used, but then if the list runs out of space, all threads would have to wait while one thread allocates a larger array and copies over the current contents. A linked list would have the same problem: creating new space has to be synchronized (as far as I'm aware at least), and new space would have to be created for each element, meaning that linked lists do not (easily) support parallel writing (again, as far as I'm aware). By using 'blocks' of memory I was able to reduce the probability of memory having to be expanded. The remaining problem was implementing parallel writing. Given that the framework I am using does not allow me to use most C# features in a multithreaded context, such as the lock-keyword or mutexes, this was also a bit of a trick. I ended up implementing everything through Interlocked-Increment. Since the blocks would each need a variable that keeps track of how many items it currently holds, and since this would then also be the index of the next unused slot, I could use interlocked increment to essentially 'claim' a slot in the array. The remaining problem, of course, is detecting when a block is full, and resolving how to allocate a new chunk, given that there may be multiple threads trying to do so at the same time. The solution I ended up going for is that only one of the threads will attempt to write to the slot that is just out of bounds, or in other words, is looking to write to index 0 of the next block's array. That thread will be tasked with allocating a new block while the others wait for the block to become available by essentially busy-waiting. This is not ideal, but then this situation of busy-waiting can only be reached once another thread is already in the process of creating a new block. This does mean that operations like inserting and deleting cannot be implemented in parallel, but that's alright for my particular use case. Reading and writing to a particular index does run into the same problem as a linked list, namely that it requires looping over the blocks. If the blocks are all a constant size though, it is possible to calculate the index of the block that contains the value that is being requested or overwritten: divide by the chunk size to get the chunk index, and do modulo chunk size to get the index within the chunk. If the chunks are reasonably large then hopefully only a handful of loop iterations are necessary to reach the desired chunk. Currently my implementation maintains a head and a tail pointer, and every chunk only contains a pointer to the next chunk. If necessary I suppose I could double-link the chunks. For reading and writing to a given index, one could then traverse from the head or the tail, depending on which is faster. With a large enough chunk size, the overhead of these additional pointers shouldn't be _too_ bad. I've yet to investigate if this approach makes good usage of CPU cache. At face value I hope that the repeated parallel accesses to successive indices of one chunk (which, given that the chunk itself is just an array, would be successive memory addresses) may cause the CPU to load (part of) a particular chunk into the cache, but I've yet to have a closer look.

You’re funny as fuck and that makes learning from you great. Cheers from Seattle

Thx

I followed the first three minutes but then he went back into his usual God mode 😃

Informative as usual. I just recently started using structs on top of your standard arrays and linked lists of various dimensions, maybe I should look into hash tables next? I'm not really sure where I'd use them though...

Some languages seem to use hash tables AS arrays. They just use integer keys when it’s an array. Or perhaps even just strings representing integers.

Hash tables and arrays are generally what you should use. If something is performance critical, different data structures can be worth investigating. A lot of performance optimization is premature.

The only data structure Lua has is associative arrays which it calls tables. Even an ordered collection (alternatively called both an array and a list as far as I can tell) is achieved by having the keys just count "up" from 1 (yes, 1) If you think about it though, 1 indexing almost makes sense in this context since we are no longer talking about actual arrays and offsetting some memory address by a certain amount. Might as well start counting at one since its the first thing in the list.

Yes, I can see it. La la la to you too.

No collisions is O(1). Java's HashMap implementation uses a linked list for each bucket, until the bucket gets big enough, at which point it switches to a Red-Black Tree, ensuring that a lookup never exceeds O(log n). Really nice for a builtin data structure.

In java we use hashmap for storing data what would be used in php .Please tell me.

too good. like, sub

1:59 Early PHP used strlen() to hash function names, if you don't believe me, see php.internals (#70691), or the PHP 1.99 source code

❤❤❤❤

Hey, I always had one concern about hash tables: If my ids are ints that can go really big, will it take a lot of memory, like allocating a very big array so that it can have an entity with an index corresponding to my hash ?

Interesting! Could this work to sort collitions on a physics engine?

This tutorial makes Lurr happy.. Ndnd doesn't know I'm on the computer... Also.. trying to delete "human horn" from search history.. any ideas?

futurama!

Hey man, I want you to know, may make you feel happy, may make you feel sad, but I know most of these characters and where they're from.

Whoever is paying your salary ought to give you a raise.

5:47

you make me study more C and ++, goddamnt...

thank you for sharing this Could some kind of "virtual geometry" like Ninite in ue5, be written in JS? Hier I found some source: Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf

For chaining, why not use another hash table with a different hash function?

Hi .. good explication ... but in 12:44 "Hermes" word .. are 6 letters ... not 5 ... is a typeout .??

Zero dislikes Nice

Yes, I could see that the video was over.

Yes! I have seen all the sneaky comments: "pedantic =/= skiled", "Lisa needs braces"... LOL!

hey can you please revisit the 3D rpg game i really am interested in that!! many people seem to be. man it was awesome

02:51 how do you know about the fancy pants data structures I've been working on

Problem with collusion resolution by using alternate addressing is that lookups slow down even if there are no collisions as just because you didn't find anything at the first location possible doesn't mean it's not in the table, it could still be at an alternate address. So you *always* must check *all* alternate addresses first before you can conclude the key is not there. This is a horrible idea IMHO considering that the main goal is to keep the number of collisions small to none in the first place. It's okay if adding or removing items is a bit slowish at times but slow lookups defeat the entire purpose of using hashtables in the first place IMO. A way better approach is to solve collisions by using linked lists and keeping collisions very rare (even if three items end up in on spot, traversing three linked lists nodes is not horribly slow and if you have large linked lists, you have way too many collisions to begin with, rather use a better hash and a bigger table) or use arrays and keep them sorted, as then you can do a binary search in the array and your O(1) will only degrade to O(log2 n) in the very worst case possible, yet O(log2 n) is still very good performance and a sorted array can easily beat a hashtable in performance when small., since people tend do forget that hashing is not for free and can be quite expensive for a good hash value. If I can only check on 8 array items in the time required to calculate a hash, I can check sorted array with 256 items in that time.

What’s ur favorite show?

Is Hermes = 5 letters also part of the super stupid concept? Haha jokes aside, I love how you explain these concepts :) Thanks!

HA HA! EAT SHI- jokes aside this video was super helpful

Bobs burgers and IT instruction

This is what you become after 10 years of programming

Bob? From Bobs burger? 😅

oh no somebody beat me to the 420th like im gonna get revenge by liking haha 421 likes go brr

New Matrix movie is not like what you expect...

HERMES is 6 letters tho

bob's burger

WHERE IS SHEEEEE?!?

Why do you sound kinda like Bob from Bob's Burgers

Data ❌ Crap ✅

👎

Informative video but can you have some respect to your God (Allah), your Creator. In the video, you named yourself as a "God", You can't just call yourself or anything else but him a God even if you are joking. A God doesn't die, get sick, have a spouse, have kids nor need any body rather we are the ones who are in need of Him. Be careful next time you joke. May Allah the All-Merciful guide you.

I really don't get the usage of “crap”, “wtf” and so on? Is that the best way you could find to make yourself sound cool? That's just sad