Create new UnionFind struct for DBSCAN

[aprokop]

This makes the code more readable, and prepares a stage for the dense
box implementation of the algorithm.

[dalg24]

Why union "one" and "two" way? I don't get it.

[aprokop]

Union-find algorithm essentially merges two (implicit) trees. In general, it does not matter which one is a root, and which one is merged into, and is usually based on which representative is smaller. However, for the boundary points, it matters, as otherwise it may lead to the bridging effect. So the boundary point tree has to be merged into the core point tree, which is what I call union_1way, which simply assigns a label.

[dalg24]

I still don't get the name

[aprokop]

Given what I described, how would you propose to call them?

[masterleinad]

Maybe be more explicit via union_boundary_core or such?

[masterleinad]

I would just not include union_1way in UnionFind then (and have the behavior in-line as before) and don't change the name of union_2way.

[aprokop]

@masterleinad I need union 1 way in UnionFind, as I do not want to expose labels.

@masterleinad @dalg24 Would you guys feel better if I change the signature to
union(int i, int j, bool one_way = false); or union(int i, int j, bool any_order = true)? It may be slightly less performant, as it will introduce an extra unnecessary if check, but should not be a biggie.

[masterleinad]

I think it's fine to have two member functions in that case but they should be self-describing. What you essentially want is a version that assigns that updates the left tree ( or the right tree), isn't it?
If so, union_merge_left and union_merge_any (or just union) would be fine with me. Alternatively, introducing a template argument force_merge_left should not have any runtime overhead and might be nicer by providing only one function.

[aprokop]

What you essentially want is a version that assigns that updates the left tree ( or the right tree), isn't it?

Well, similar, but there is no left tree and right tree. There are two trees, one consisting of a single vertex (corresponding to the boundary point), and one other tree. To me, left is completely confusing, and does not make sense.

[masterleinad]

OK. Then calling this function has special requisites, i.e. one of them having only a single vertex, in that case I would certainly use two different names, maybe union_with_single_vertex_tree or so.

[dalg24]

I still don't get the name

[dalg24]

Why do you want to expose this? This is an implementation of the callback. Take the labels like you did before and create your union find in the callback constructor.

[aprokop]

Well, I could do that in this PR, but I would have to move it out in the dense box PR, as I will also need to update this outside of the callback. So, rather than passing the labels around I like it better to pass union-find struct around. This also makes sense logically, as we could change the way union-find struct implemented (if desired) without changing the callback.

[aprokop]

@dalg24 Do my comments address your concerns?

[aprokop]

Two SYCL timeouts, but otherwise tests pass.

[aprokop]

@dalg24 Should have addressed your comments.

I renamed union_2way and union_1way to merge and merge_into. Could not use union because it's a reserved word. Union-find is also called merge-find sometimes, so these names make some sense. I could have renamed UnionFind as a MergeFind, but I like UnionFind better.

[masterleinad]

Fine with me.

[dalg24]

I'd prefer if you squash merged or rewrote history