Skip to content

Re-opened previous PR with suggested improvements and fixes.#185

Merged
jrtom merged 8 commits intojrtom:masterfrom
tomnelson:master
Jan 14, 2018
Merged

Re-opened previous PR with suggested improvements and fixes.#185
jrtom merged 8 commits intojrtom:masterfrom
tomnelson:master

Conversation

@tomnelson
Copy link
Copy Markdown
Contributor

This is mostly about LayoutModel::getLocations() but also has additional javadocs

 Changes to be committed:
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/algorithms/util/IterativeContext.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/CircleLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/FRBHVisitorLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/FRLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/ISOMLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/IterativeLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/KKLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/LayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/RadialTreeLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/SpringBHVisitorLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/SpringLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/StaticLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/TreeLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/DefaultLayoutModelChangeSupport.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LoadingCacheLayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/Point.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/PolarPoint.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/BarnesHutQuadTree.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/Circle.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/Node.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/Rectangle.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/util/NetworkNodeAccessor.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/util/VisRunnable.java
	modified:   jung-algorithms/src/test/java/edu/uci/ics/jung/layout/algorithms/FRBHIteratorLayoutAlgorithm.java
	new file:   jung-algorithms/src/test/java/edu/uci/ics/jung/layout/algorithms/ForceObjectIterator.java
	modified:   jung-algorithms/src/test/java/edu/uci/ics/jung/layout/algorithms/SpringBHIteratorLayoutAlgorithm.java
	modified:   jung-algorithms/src/test/java/edu/uci/ics/jung/layout/spatial/FRLayoutsTest.java
	modified:   jung-samples/src/main/java/edu/uci/ics/jung/samples/BarnesHutVisualizer.java
	modified:   jung-samples/src/main/java/edu/uci/ics/jung/samples/NodeCollapseDemo.java
	modified:   jung-visualization/src/main/java/edu/uci/ics/jung/visualization/BasicVisualizationServer.java
	modified:   jung-visualization/src/main/java/edu/uci/ics/jung/visualization/layout/AggregateLayoutModel.java
	modified:   jung-visualization/src/main/java/edu/uci/ics/jung/visualization/layout/AnimationLayoutAlgorithm.java
	modified:   jung-visualization/src/main/java/edu/uci/ics/jung/visualization/spatial/AbstractSpatial.java
	modified:   tools/deploy_snapshots.sh
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/util/NetworkNodeAccessor.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/util/RadiusNetworkNodeAccessor.java
 Changes to be committed:
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/AbstractLayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/DefaultLayoutModelChangeSupport.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/DefaultLayoutStateChangeSupport.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LoadingCacheLayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/Point.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/PolarPoint.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/Node.java
	modified:   jung-algorithms/src/test/java/edu/uci/ics/jung/layout/spatial/FRLayoutsTest.java
	modified:   jung-visualization/src/main/java/edu/uci/ics/jung/visualization/layout/AggregateLayoutModel.java
 Changes to be committed:
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/FRBHVisitorLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/AbstractLayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LoadingCacheLayoutModel.java
 Changes to be committed:
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/CircleLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/FRBHVisitorLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/algorithms/SpringBHVisitorLayoutAlgorithm.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/AbstractLayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/model/LoadingCacheLayoutModel.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/BarnesHutQuadTree.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/spatial/Node.java
	modified:   jung-algorithms/src/main/java/edu/uci/ics/jung/layout/util/RadiusNetworkNodeAccessor.java
	modified:   jung-samples/src/main/java/edu/uci/ics/jung/samples/BarnesHutVisualizer.java
…ances. Sometimes the test would fail with very close floating point numbers

 Changes to be committed:
	renamed:    jung-algorithms/src/test/java/edu/uci/ics/jung/layout/spatial/CircleTest.java -> jung-algorithms/src/test/java/edu/uci/ics/jung/layout/spatial/ShapesTest.java
	modified:   jung-visualization/src/test/java/edu/uci/ics/jung/visualization/spatial/rtree/RTreeTest.java
}
return -1;
}
}
Copy link
Copy Markdown
Contributor Author

@tomnelson tomnelson Jan 13, 2018

Choose a reason for hiding this comment

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

This hack is because the test would sometimes fail (as in your most recent push) because of comparing floating point values like this (in italics):
Failed tests: testOne(edu.uci.ics.jung.visualization.spatial.rtree.RTreeTest): expected:<java.awt.geom.Rectangle2D$Double[x=2.9168632067831934,y=0.1405494536367291,w=570.535341820459,h=599.8594505463633]> but was:<java.awt.geom.Rectangle2D$Double[x=2.9168632067831934,y=0.1405494536367291,w=570.5353418204589,h=599.8594505463633]>

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Yep. I think I actually expressed some concern about the direct comparison of doubles in some previous PR; I don't remember the exact context, but in general we probably don't want to be doing that.

 Changes to be committed:
	modified:   jung-visualization/src/test/java/edu/uci/ics/jung/visualization/spatial/rtree/RTreeTest.java
Copy link
Copy Markdown
Owner

@jrtom jrtom left a comment

Choose a reason for hiding this comment

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

Looks pretty good, just a few cleanup comments. Thanks for sticking with this. :)

Also, I am really happy with how the getLocations() thing worked out, that's just a much nicer API all around. :)

import org.slf4j.LoggerFactory;

/**
* an Event system for LayoutModels to announce the change in the location of Nodes This replaces
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

punctuation missing

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

see other comment about event system

/**
* This subclass of FRLayoutAlgorithm applies a Barnes-Hut QuadTree optimization during the
* calculation of node repulsion
* calculation of node repulsion. The purpose of the Barnes-Hut optimization is to reduce the n-body
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

I would say rather than "the n-body problem" "the number of calculations required"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

and here i wuz getting all graph-theory-like.....

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

IME "n-body problem" is from physics, but OK :)

/**
* Changes the layout coordinates of {@code node} to {@code x, y}.
*
* @param node
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

missing descriptions for params

* This exists so that LayoutModel will not have dependencies on java awt or swing event classes
*/
interface ChangeSupport {
ChangeSupport getChangeSupport();
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

missing Javadoc

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

i have an event redesign ready to go. This will be OBE :)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

I have no idea what you mean by OBE, but I assume that this means that this will be changing. :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

overcome by events

/**
* @param ox coordinate of another location
* @param oy coordinate of another location
* @returnthe square of the distance between this Point and the passed location
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

missing space after @return

MutableNetwork<String, Number> network;
BarnesHutQuadTree<String> tree;

Map<String, Point> elements = Maps.newHashMap();
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Style nit: this (and the line below) are fine, but now that the diamond operator is available (as of Java 7) it's actually just as convenient to do

Map<String, Point> elements = new HashMap<>();

and uses slightly fewer characters if you care about that sort of thing.

The main reason why the parameterless Maps.newHashMap() and Sets.newHashSet() were created was to get around the requirement for redundantly specifying the generic types.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

interesting. I would have bet that you'd go for the factory method over the CTOR any day.

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

In this context I don't have a strong preference. I'm pretty sure that those specific factory methods would never have existed if it weren't for the former redundant type spec requirement, though.

}

private boolean closeEnough(double left, double right) {
return Math.abs(left - right) < 0.001;
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Please define a constant for the tolerance.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'm delighted with your idea for getLocations too.


private boolean closeEnough(Rectangle2D left, Rectangle2D right) {
return left.equals(right)
|| (closeEnough(left.getMinX(), right.getMinX())
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

I would be inclined to use the Truth library for this; jbduncan@ and I will probably convert most/all of the JUNG test assertions to use Truth once things settle down a bit. Specifically, Truth provides facilities for comparing double values within a specified tolerance: https://google.github.io/truth/floating_point

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

sounds like something for a future PR. I like that idea.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I like this idea too. I'll go and open an issue on this for now, if we don't already have one already, just so we don't lose track of it. :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@jbduncan I pushed a commit to use 'truth' in my latest PR. Please have a look to see if it can be improved. I noticed that there are a number of other places in jung-algorithms legacy code where a tolerance is used in a unit test comparison. Using 'truth' really cleans up the code. Kudos to the author(s) for making it so readable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@tomnelson I've had a look and made some suggestions! Please let me know what you think over there. :)

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.

3 participants