Skip to content

Commit

Permalink
Remove the last traces of the Tree/Forest types and the classes that …
Browse files Browse the repository at this point in the history 
…implement them.
  • Loading branch information
@jrtom
jrtom committed Jun 8, 2017
1 parent 01effe3 commit 01f3d8f
Show file tree
Hide file tree
Showing 6 changed files with 1 addition and 1,206 deletions.
96 changes: 0 additions & 96 deletions jung-api/src/main/java/edu/uci/ics/jung/graph/Forest.java
View file

This file was deleted.

52 changes: 0 additions & 52 deletions jung-api/src/main/java/edu/uci/ics/jung/graph/Tree.java
View file

This file was deleted.

105 changes: 1 addition & 104 deletions jung-api/src/main/java/edu/uci/ics/jung/graph/util/TreeUtils.java
View file
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,7 @@
*/
package edu.uci.ics.jung.graph.util;

import java.util.ArrayList;
import java.util.Collection;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

import com.google.common.base.Preconditions;
Expand All @@ -23,31 +20,15 @@
import com.google.common.graph.Network;

import edu.uci.ics.jung.graph.CTreeNetwork;
import edu.uci.ics.jung.graph.Forest;
import edu.uci.ics.jung.graph.MutableCTreeNetwork;
import edu.uci.ics.jung.graph.Tree;
import edu.uci.ics.jung.graph.TreeNetworkBuilder;

/**
* Contains static methods for operating on instances of <code>Tree</code>.
*/
// TODO: add tests
public class TreeUtils
{
/**
* @param <V> the vertex type
* @param <E> the edge type
* @param forest the forest whose roots are to be returned
* @return the roots of this forest.
*/
public static <V,E> List<V> getRoots(Forest<V,E> forest)
{
List<V> roots = new ArrayList<V>();
for(Tree<V,E> tree : forest.getTrees()) {
roots.add(tree.getRoot());
}
return roots;
}

public static <N> Set<N> roots(Graph<N> graph) {

This comment has been minimized.

Sign in to view

Copy link
@jbduncan

jbduncan Jun 9, 2017 •
edited
Loading

Contributor

@jrtom I'd be happy to eventually see this method return a Stream for the purposes of laziness and "new"-ness, but I don't know if laziness is proven to be better in this case than returning a pre-calculated Set by some metric, and I also don't know if you're considering making JUNG 3.0 require Java 8 or not...
Set<N> roots = new HashSet<N>();
for (N node : graph.nodes()) {
Expand Down Expand Up @@ -113,30 +94,6 @@ public static <N,E> MutableCTreeNetwork<N,E> getSubTree(CTreeNetwork<N,E> tree,
return subtree;
}

/**
* Returns the subtree of <code>tree</code> which is rooted at <code>root</code> as a <code>Forest</code>.
* The tree returned is an independent entity, although it uses the same vertex and edge objects.
* @param <V> the vertex type
* @param <E> the edge type
* @param forest the tree whose subtree is to be extracted
* @param root the root of the subtree to be extracted
* @return the subtree of <code>tree</code> which is rooted at <code>root</code>
* @throws InstantiationException if a new tree of the same type cannot be created
* @throws IllegalAccessException if a new tree of the same type cannot be created
*/
@SuppressWarnings("unchecked")
// FIXME: remove this method once we no longer need it
public static <V,E> Tree<V,E> getSubTree(Forest<V,E> forest, V root) throws InstantiationException, IllegalAccessException
{
if (!forest.containsVertex(root))
throw new IllegalArgumentException("Specified tree does not contain the specified root as a vertex");
Forest<V,E> subforest = forest.getClass().newInstance();
subforest.addVertex(root);
growSubTree(forest, subforest, root);

return subforest.getTrees().iterator().next();
}

/**
* Populates <code>subtree</code> with the subtree of <code>tree</code>
* which is rooted at <code>root</code>.
Expand All @@ -155,30 +112,6 @@ public static <N,E> void growSubTree(CTreeNetwork<N,E> tree, MutableCTreeNetwork
}
}

/**
* Populates <code>subtree</code> with the subtree of <code>tree</code>
* which is rooted at <code>root</code>.
* @param <V> the vertex type
* @param <E> the edge type
* @param tree the tree whose subtree is to be extracted
* @param subTree the tree instance which is to be populated with the subtree of <code>tree</code>
* @param root the root of the subtree to be extracted
*/
// FIXME: remove this once it's no longer needed
// do we even need this as a separate method from getSubTree?
public static <V,E> void growSubTree(Forest<V,E> tree, Forest<V,E> subTree, V root) {
if(tree.getSuccessorCount(root) > 0) {
Collection<E> edges = tree.getOutEdges(root);
for(E e : edges) {
subTree.addEdge(e, tree.getEndpoints(e));
}
Collection<V> kids = tree.getSuccessors(root);
for(V kid : kids) {
growSubTree(tree, subTree, kid);
}
}
}

/**
* Connects {@code subTree} to {@code tree} by attaching it as a child
* of {@code subTreeParent} with edge {@code connectingEdge}.
Expand Down Expand Up @@ -210,25 +143,6 @@ public static <N, E> void addSubTree(MutableCTreeNetwork<N, E> tree, CTreeNetwor
addFromSubTree(tree, subTree, subTreeRoot);
}

/**
* Connects <code>subTree</code> to <code>tree</code> by attaching it as a child
* of <code>node</code> with edge <code>connectingEdge</code>.
* @param <V> the vertex type
* @param <E> the edge type
* @param tree the tree to which <code>subTree</code> is to be added
* @param subTree the tree which is to be grafted on to <code>tree</code>
* @param node the parent of <code>subTree</code> in its new position in <code>tree</code>
* @param connectingEdge the edge used to connect <code>subtree</code>'s root as a child of <code>node</code>
*/
// FIXME: remove this
public static <V,E> void addSubTree(Forest<V,E> tree, Forest<V,E> subTree,
V node, E connectingEdge) {
if (node != null && !tree.containsVertex(node))
throw new IllegalArgumentException("Specified tree does not contain the specified node as a vertex");
V root = subTree.getTrees().iterator().next().getRoot();
addFromSubTree(tree, subTree, connectingEdge, node, root);
}

private static <N, E> void addFromSubTree(MutableCTreeNetwork<N, E> tree, CTreeNetwork<N, E> subTree,
N subTreeRoot) {
for (E edge : subTree.outEdges(subTreeRoot)) {
Expand All @@ -237,21 +151,4 @@ private static <N, E> void addFromSubTree(MutableCTreeNetwork<N, E> tree, CTreeN
addFromSubTree(tree, subTree, child);
}
}

private static <V,E> void addFromSubTree(Forest<V,E> tree, Forest<V,E> subTree,
E edge, V parent, V root) {

// add edge connecting parent and root to tree
if(edge != null && parent != null) {
tree.addEdge(edge, parent, root);
} else {
tree.addVertex(root);
}

Collection<E> outEdges = subTree.getOutEdges(root);
for(E e : outEdges) {
V opposite = subTree.getOpposite(root, e);
addFromSubTree(tree, subTree, e, root, opposite);
}
}
}
Loading

4 comments on commit 01f3d8f

@jbduncan
Copy link
Contributor

Choose a reason for hiding this comment

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

@jrtom Is there a plan to replace these classes with equivalent ones from Guava common.graph? Or are you working under the assumption that Trees aren't that useful?

@jrtom
Copy link
Owner Author

@jrtom jrtom commented on 01f3d8f Jun 9, 2017

Choose a reason for hiding this comment

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

@jbduncan There are tree-related classes in the common.graph jung-api@ as of a commit shortly before this one: https://github.com/jrtom/jung/tree/common.graph/jung-api/src/main/java/edu/uci/ics/jung/graph

Specifically, the CTree classes. Those are likely going to get renamed (suggestions welcome) but they do in fact exist. :)

It's an open question right now as to whether those will end up existing in common.graph or in JUNG, but I wanted them to be available in JUNG because a lot of existing code (layouts and samples) assumed that we had trees, and I do think that they're generally useful.

@jbduncan
Copy link
Contributor

Choose a reason for hiding this comment

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

Aha, I see! Many thanks for the clarification @jrtom.

Is the C in CTree short for anything in particular?

If CTree doesn't make it to Guava, then calling it JungTree might be a possibility? (But having said that, I don't think it's a very good idea, because it sounds a bit egotistical to me. 😉)

Or if the obvious choice of Tree no longer exists in the JUNG 3.0-SNAPSHOT code base (or is planned for removal), then CTree can eventually be renamed to that.

Thought I'd throw in my two cents. 😃

@jrtom
Copy link
Owner Author

@jrtom jrtom commented on 01f3d8f Jun 9, 2017

Choose a reason for hiding this comment

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

"CTree" was always intended to be a temporary name. In this case the "C" stands for "common" as in (Guava's) common.graph. I needed a separate name while I navigated the transition, and wanted to not spend time spinning on name selection at the time, and that's what I came up with.

I agree that JungTree is not a good name for at least a couple of reasons. :)

Since JUNG's original Tree has now been nuked, that name is certainly available.

Moving this discussion to issue #83 so that it doesn't get buried here.

Thanks for your feedback.

Please sign in to comment.