Skip to content

49 add union find data structure#62

Open
c-m-elliott wants to merge 103 commits into
mainfrom
49-add-union-find-data-structure
Open

49 add union find data structure#62
c-m-elliott wants to merge 103 commits into
mainfrom
49-add-union-find-data-structure

Conversation

@c-m-elliott

Copy link
Copy Markdown

So far, this includes the interfaces UnionFind, SortedUnionFind, PersistentUnionFind and PersistentSortedUnionFind as well as the abstract classes AbstractImmutableUnionFind and AbstractImmutableSortedUnionFind. It also contains a naive implementation of SortedUnionFind based on a HashMap of TreeSets (SortedTreeSetUnionFind). There is a set of tests (SortedUnionFindTest), but there seems to be some kind of problem regarding null values which is causing the JDK21 PackageSanityTest to fail. This in particular is something I'd appreciate input on. Thanks!

Colleen added 30 commits May 25, 2026 13:52
… mismatches that will be sorted out later on if I decide to stick with HashMaps
…) as static method problematic due to variable type
Colleen and others added 22 commits July 16, 2026 18:19
… and commented out debug output (designed together with c-m-elliott in a meeting)
…red helper methods to ParentPointerTree;

return type of getAllSubsets() may need to be changed in the future
@c-m-elliott

Copy link
Copy Markdown
Author

@baierd could you please take a look at ParentPointerTreeUnionFind? It uses ParentPointerTree and TreeNode which both don't implement any standard interfaces at the moment. For example, TreeNode could implement Object and ParentPointerTree could have Collection. They would mean quite a few additional methods which I don't need for the union-find. I am wondering whether they might be valuable further down the line (in case of potential future uses) or just add bulk without real benefit. What do you think?

@baierd

baierd commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

For example, TreeNode could implement Object

That would make no sense. Every concrete instance of a class is automatically a object.

and ParentPointerTree could have Collection.

Do you really want to implement everything from Collection just for your Union-Find?

You don't need to implement a interface if they are not helpful.

@c-m-elliott

Copy link
Copy Markdown
Author

Thanks, then I will leave them as they are. I don't see myself needing Collection features with what I have planned at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

Add Union-Find Data-Structure

2 participants