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

use hashset instead of hashmap and &Node instead of Id #2

Open
luiswirth opened this issue Jun 14, 2020 · 2 comments
Open

use hashset instead of hashmap and &Node instead of Id #2

luiswirth opened this issue Jun 14, 2020 · 2 comments
Labels
refactoring Refactoring or rewrite of existing code

Comments

@luiswirth
Copy link
Owner

The current implementation of hasherlife uses IDs as handles to the actual Nodes in the HashMap<ID, Node>. Instead it would be sufficient to use references (&Node) into a HashSet<Node>.

The largest problem with this refactoring lies in satisfying the borrowck because there are a lot of lifetimes involved. I'm not sure if it is even feasible to do a trivial refactoring or if it's necessary to use different data structures altogether. Maybe there is unsafe code necessary.

Another problem is the immutability of the hashset entries. We need a different way to memoize the computed Inode::result because we can't mutate the Nodes.

@luiswirth luiswirth added the enhancement New feature or request label Jun 14, 2020
@luiswirth luiswirth changed the title use hashset instead of hashnap and &Node instead of Id use hashset instead of hashmap and &Node instead of Id Jun 14, 2020
@luiswirth luiswirth added refactoring Refactoring or rewrite of existing code and removed enhancement New feature or request labels Jun 14, 2020
@luiswirth
Copy link
Owner Author

luiswirth commented Jun 19, 2020

I'm not quite sure but I think we just need to store Refcell<Node> instead of &Node in the structs to eliminate lifetime problems.

Here are some references or ideas, which might help in solving this problem:

@luiswirth
Copy link
Owner Author

For now we should probably switch to bimap because we map in both directions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Refactoring or rewrite of existing code
Projects
None yet
Development

No branches or pull requests

1 participant