Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hashtable documentation #93

Merged
merged 11 commits into from
Jun 17, 2024

Conversation

scriptandcompile
Copy link
Contributor

No description provided.

Comment on lines -73 to -80
#[derive(Debug, PartialEq, Eq)]
struct TestKey(usize);

impl Hashable for TestKey {
fn hash(&self) -> usize {
self.0
}
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this is valuable, because this way we test that the hash table works with hashable elements.

What's interesting here is that no tests broke, which means that we aren't testing the actual placement of keys in the table (Testkey(i) would be placed in the i-th bucket, but i, would be placed in the hash(i) % length bucket).

I think this is a bit involved, and I'm not sure how educational it is, so I think it's fine to remove this. wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. What was actually upsetting about this was that the key educational bit of a hash table, the bit that makes it 'different' than other data structures, is the hash function...which we are just setting it to the item! which means it might as well just be an array.

But wait! There is more!

We are using a vector and a linked list internally! Which is...just. no.

We definitely should have a linked list as a structure as an example, but we shouldn't be using them internally. The cache thrashing they cause is just not worth their use in modern code. The cost vs benefit just fails. Arena's are significantly better choices and that goes doubly so given rust's hate of multi-borrow mechanics.

vec of Option for storage, K is the index into the vec, v is the value in the vec, and we are off and running. The same could be done with the b-tree but I just couldn't be bothered since I've been focusing on the doc's instead of the core implementation.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you'd like to implement that, I'm more than happy to review it!

I still think it's valuable to show suboptimal implementations though: if someone is starting, they should have access to both the dumb, easy implementation and the nicer, optimized, linear-probing implementation.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm merging this, feel free to open a separate PR!

@alexfertel alexfertel merged commit e709198 into alexfertel:main Jun 17, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants