jgrapht-developers Mailing List for JGraphT
Brought to you by:
barak_naveh,
perfecthash
Menu
▾
▴
jgrapht-developers — A discussion list for JGraphT developers.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(4) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(18) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(7) |
Aug
(5) |
Sep
(7) |
Oct
|
Nov
|
Dec
(14) |
| 2006 |
Jan
(6) |
Feb
(1) |
Mar
(3) |
Apr
(6) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2007 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Timmy J. <tim...@ya...> - 2020-07-27 14:21:31
|
<div>Hello all,</div><div> </div><div>I came across jgrapht, and have been playing around with it for a few hours now.</div><div> </div><div>I have a question about the licensing aspects of writing a port/derivative work using some of the APIs of jgrapht. Looking at the licensing page, suppose I decided to choose LGPL 2.1, can anyone:</div><div> 1. Confirm that a port/using the APIs with custom implementation in a different language (from Java, that is) is all right?</div><div> 2. Point to to a resource about what exactly I would need to include in my derivative work to be compliant with the licensing terms? </div><div> </div><div>Thanks!</div><div> </div><div>Timmy</div> |
|
From: Anjali M. <anj...@gm...> - 2019-01-07 05:23:17
|
Hi, I am a student pursuing my 4th year of a 5 year Computer Science program. I have always wanted to try my hand at open source contribution and am a GSoC 2019 aspirant. I discovered JGraphT from the 2018 GSoC projects and am very interested to contribute to it. Java is my primary programming language and I have taken courses on Data Structures, Algorithms and Graph Theory. I also do have some research experience as part of a summer fellowship I did two summers ago. I went through the "Open tasks, projects and collaboration" page and found this task <https://github.com/jgrapht/jgrapht/wiki/Open-tasks,-projects-and--collaboration-ideas#simple-cycles-orgjgraphtalgcycle> as a good place to start from. I wanted to know if this task has already been taken up/completed. If yes, then which other simple tasks would you recommend for a beginner? If not, are you willing to discuss a solution approach with me? It would be of great help if you could guide my through my initial contribution as I am very new to the open source world. I am extremely enthusiastic and excited to be contributing to this project. Regards, Anjali |
|
From: Edwin Ma <em...@co...> - 2018-05-14 09:16:21
|
Hi, I'm interested in contributing to this project and have just set up the development environment. I'm currently operating on macOS Sierra and using Maven 3 with Java 9. I just have a few questions regarding existing errors and warnings after running the following commands: mvn clean mvn verify mvn checkstyle:check -P checkstyle mvn javadoc:aggregate Specifically, after running 'mvn verify', I received warnings regarding the use of deprecated API in input files, and that some input files use unchecked or unsafe operations. After running 'mvn javadoc:aggregate', I see some similar warning as well as errors regarding the lack of a module descriptor. Are these expected and meant to be ignored? Each step does successfully complete. I'm looking to implement the planarity test with the appropriate certificates based off of the implementations of Hopcroft-Tarjan planarity testing algorithm in LEDA as suggested in https://github.com/jgrapht/jgrapht/pull/416 Best, Edwin |
|
From: Stan R. <sta...@gm...> - 2011-09-02 03:03:34
|
Hi, Since ConnectivityInspector.connectedSets computes disjoint sets, the result type should be Set<Set<V>> instead of List<Set<V>>. This also applies to the field 'connectedSets'. Thanks, stan |
|
From: John V. S. <js...@gm...> - 2009-04-09 17:21:23
|
Andreas Maunz wrote: > Hello, I am a little surprised that there is no Maximum Common Subgraph > (MCS) implementation available in jgrapht. It shouldn't be difficult, > since MSC can be reduced to Maximum Clique (MC) detection, which jgrapht > apparently already supports. > What are the reasons for this? Can anybody point me towards an existing > implementation outside jgrapht? I have been looking for one, but no > success. If none exists, I would be willing to collaborate in writing one. Hi Andreas, JGraphT grows by accretion (I am like a librarian accepting used book donations and shelving them). If you send me an MCS implementation together with a unit test, I'd be glad to put it in the next release. Thanks, JVS |
|
From: Andreas M. <an...@ma...> - 2009-04-09 08:14:28
|
Hello, I am a little surprised that there is no Maximum Common Subgraph (MCS) implementation available in jgrapht. It shouldn't be difficult, since MSC can be reduced to Maximum Clique (MC) detection, which jgrapht apparently already supports. What are the reasons for this? Can anybody point me towards an existing implementation outside jgrapht? I have been looking for one, but no success. If none exists, I would be willing to collaborate in writing one. Best regards, Andreas -- http://www.maunz.de Let's face the obvious. Yesterday we were nerds. Today we're the cognitive elite. Let's conquer. - Chester G. Edwards |
|
From: John V. S. <js...@gm...> - 2009-01-16 01:06:31
|
If you're in the San Francisco bay area, the Lise Getoor talk tomorrow may be of interest: http://infolab.stanford.edu/infoseminar/ JVS |
|
From: John V. S. <js...@gm...> - 2009-01-15 01:00:13
|
https://sourceforge.net/forum/message.php?msg_id=6106792 JVS |
|
From: John V. S. <js...@gm...> - 2008-09-29 08:50:57
|
The version number has jumped to 0.8 because JGraphT now requires Java 1.6 at both buildtime and runtime. This was necessary so that we could start using ArrayDeque, which speeds up the iterators and some of the algorithms. If you are stuck on an earlier JVM/JDK, either continue to use the JGraphT 0.7.x series until you can make the move, or use retroweaver/translator to create a backport. Some news: JGraphT has moved under the umbrella of The Eigenbase Project, another open source organization I am actively involved in. The project is accepting donations, and those are tax deductible because Eigenbase is a 501(c)(3) public charity. Contributions will be used to set up hosted services such as Cruise Control and code coverage reporting in order to keep JGraphT quality high. If you use JGraphT in your application, please consider making a donation today; JGraphT is entirely volunteer supported. Donation links are available at http://www.eigenbase.org as well as on the JGraphT donation page at Sourceforge. Note that JGraphT links have not moved, and hosting is still at Sourceforge.net. If you have questions about any of this, please let me know. Thanks, and now back to the usual release announcement! This release includes a number of bugfixes and contributions which have accumulated since the 0.7.3 release. You can find a description of the changes here: http://jgrapht.wikispaces.com/Release0.8.0 Big thanks to all who made suggestions and code contributions for this release, especially Tim Shearouse, Ilya Razenshteyn and Peter Giles for new algorithm implementations, plus Jason Lenderman and Ross Judson for performance improvements. JVS |
|
From: John V. S. <js...@gm...> - 2008-07-05 00:02:24
|
Christian Soltenborn wrote: > Hi John and the rest, > > does anybody mind if I check in a META-INF/MANIFEST.MF file? This would > allow to use jgrapht as an OSGi plug-in out of the box (e.g. for use > within Eclipse RCP applications, which is my use case). Go for it. JVS |
|
From: Christian S. <cso...@gm...> - 2008-07-04 13:15:05
|
Hi John and the rest, does anybody mind if I check in a META-INF/MANIFEST.MF file? This would allow to use jgrapht as an OSGi plug-in out of the box (e.g. for use within Eclipse RCP applications, which is my use case). Cheers, Christian -- Fred Allen: "What's on your mind, if you will allow the overstatement?" |
|
From: John V. S. <js...@gm...> - 2008-05-23 06:36:50
|
I'll be at OSCON in Portland, Oregon in July. I'll be giving a talk on another open-source project I work on (LucidDB), but if you're going to be there too and want to chat about JGraphT, email me and we can meet up. http://en.oreilly.com/oscon2008/public/schedule/detail/2781 JVS |
|
From: John V. S. <js...@gm...> - 2008-05-17 18:30:40
|
I've enlisted JGraphT's Subversion repository in ohloh, a service which analyzes open-source projects: http://www.ohloh.net/projects/jgrapht It produces some fun factoids. JVS |
|
From: John V. S. <js...@gm...> - 2008-01-28 03:34:06
|
This is a maintenance release which includes a number of bugfixes and contributions which have accumulated since the 0.7.2 release. You can find a description of the changes here: http://jgrapht.wikispaces.com/Release0.7.3 In particular, you can actually access the result of k-shortest-paths now! Sorry about that package-access oversight in the last release. JVS |
|
From: Christian S. <cso...@gm...> - 2007-11-07 16:18:34
|
Hi Ulrich, have a look at the graph object your edges belong to. It has methods getEdgeSource and getEdgeTarget. Cheers, Chris Ulrich Voigt schrieb: > Hi, > > I have just started to work with JGraphT and I am quite happy with it! > > But I have some questions about the implementation of the DefaultWeightedEdge class. > The IntrusiveEdge class contains the source and the target of the edge. But classes that override it (e.g. DefaultWeightedEdge) do not have access to these fields? Why? > > In my case I want to subclass the DefaultWeightedEdge class to store the properties of a logical network connection. For this case I would like to have the information about the source and the target. At the moment I would have to define my own source and target fields and I don't like that :-) > > Thanks for your answers! > > Uli |
|
From: Ulrich V. <voi...@gm...> - 2007-11-07 13:01:52
|
Hi, I have just started to work with JGraphT and I am quite happy with it! But I have some questions about the implementation of the DefaultWeightedEdge class. The IntrusiveEdge class contains the source and the target of the edge. But classes that override it (e.g. DefaultWeightedEdge) do not have access to these fields? Why? In my case I want to subclass the DefaultWeightedEdge class to store the properties of a logical network connection. For this case I would like to have the information about the source and the target. At the moment I would have to define my own source and target fields and I don't like that :-) Thanks for your answers! Uli -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger |
|
From: John V. S. <js...@gm...> - 2007-11-05 04:03:46
|
Lucas Scharenbroich wrote: > All, > > Please find an implementation of a BipartiteGraph attached. I've seen > this requested a few times in the archives and, since I need it myself > to build upon, I thought I'd post the implementation for feedback and > comments. Hi Lucas, Sorry for the very slow response (been busy at work)...below are some review comments from me. > 1) I implemented BipartiteGraph as a GraphDelegator. This seemed to be > the path of least resistance. Is there a better place in the class > hierarchy to put this? The alternative would be to implement it as a constraining mask on an underlying listenable graph. The constraining part involves adding a listener to prevent the bipartite condition from being violated on edge addition. The listener approach has the advantage of decoupling the bipartite aspect from other structural aspects of the graph. It also helps make sure the mask stays in sync with the underlying graph. The problem is that currently the listener framework does not support constraints; i.e. a listener cannot cleanly veto a change. (It can veto it uncleanly by throwing a RuntimeException, leaving the graph in violation of the constraint; there are other issues such as atomicity for methods like removeAllEdges.) So, if we wanted to do it this way, we would need to implement constraints generically first, and then this would be the first usage. If not, the GraphDelegator approach seems fine; we could always retrofit later for constraints. > 2) I track the membership of vertices to partitions by keeping a private > Map. This is potentially inefficient since Vertex object references are > duplicated. I can't come up with a more space-efficient approach at the > moment and this was "good enough" for a first implementation. Fine with me. The partition vertex sets are also useful for constructing subgraph views. The map approach can also be generalized to k-partite graphs later; this also requires generalizing the notion of partition identifier beyond a fixed enum. > 3) The traversal in the constructor to build a bipartite graph from the > input graph is a bit messy. Is a TraversalListener the best way to do this? > Most of the method are self-explanatory -- I just added checks to ensure > that the bipartite property holds after each method. I also added > additional methods for adding vertices to specific partitions and > getting the set of partition vertices. I have junit tests for this code > that I have not posted yet. I don't know of anything simpler than the traversal listener. But there is one small tweak needed for directed graphs. For the example in your Javadoc, if you start with v3, you might put v4 in the same partition, since it will be seen before traversing e3; then you'll get an error when e3 is traversed. The tweak is to wrap g using Graphs.undirectedGraph and give that to the DFS so that it will ignore edge direction. One question: why is the behavior for addEdge(V,V) and addEdge(V,V,E) different? Seems like both should complain about constraint violations. > Obviously, there is quite a bit more documentation to write before it's > in sufficient shape for submission, but I thought it would be good to > get some feedback. Send me the final version along with unit tests, and I'll commit to Subversion. JVS |
|
From: John V. S. <js...@gm...> - 2007-10-10 05:58:32
|
Lucas Scharenbroich wrote: > All, > > Please find an implementation of a BipartiteGraph attached. I've seen > this requested a few times in the archives and, since I need it myself > to build upon, I thought I'd post the implementation for feedback and > comments. Thanks Lucas. I'll take a look at this for the next release. Review comments from other developers would be appreciated. JVS |
|
From: Lucas S. <lsc...@jp...> - 2007-10-07 03:13:22
|
All,
Please find an implementation of a BipartiteGraph attached. I've
seen this requested a few times in the archives and, since I need it
myself to build upon, I thought I'd post the implementation for
feedback and comments.
Here are some items I think could be up for debate:
1) I implemented BipartiteGraph as a GraphDelegator. This seemed to
be the path of least resistance. Is there a better place in the
class hierarchy to put this?
2) I track the membership of vertices to partitions by keeping a
private Map. This is potentially inefficient since Vertex object
references are duplicated. I can't come up with a more space-
efficient approach at the moment and this was "good enough" for a
first implementation.
3) The traversal in the constructor to build a bipartite graph from
the input graph is a bit messy. Is a TraversalListener the best way
to do this?
Most of the method are self-explanatory -- I just added checks to
ensure that the bipartite property holds after each method. I also
added additional methods for adding vertices to specific partitions
and getting the set of partition vertices. I have junit tests for
this code that I have not posted yet.
Obviously, there is quite a bit more documentation to write before
it's in sufficient shape for submission, but I thought it would be
good to get some feedback.
Thank you,
-Lucas
/**
* A bipartite delegator enforces the partitioning of the graph
vertices into
* two disjoint sets. An additional addVertex() method is added
which allows
* the assignment of vertices to a one partition or the other. The
addEdge()
* methods are checked and the addition will fail if the bipartite
constraints
* are violated
*
* @author Lucas J. Scharenbroich
* @since Oct. 5, 2007
*/
import java.util.*;
import org.jgrapht.*;
import org.jgrapht.graph.*;
import org.jgrapht.traverse.*;
import org.jgrapht.event.*;
public class BipartiteGraph<V, E> extends GraphDelegator<V, E>
{
public enum Partition {V1, V2};
protected final Map<Partition, Set<V>> vertexSetMapping =
new EnumMap<Partition, Set<V>>(Partition.class);
/**
* Constructor for BipartiteGraph.
*
* @param g the backing graph over which the bipartite topology
* is to be constrained
*/
public BipartiteGraph(final Graph<V, E> g)
{
super(g);
vertexSetMapping.put(Partition.V1, new HashSet<V>());
vertexSetMapping.put(Partition.V2, new HashSet<V>());
// Run through the current set of vertices and edges and
// place them arbitrarily is the two classes. This is
// really the best we can do with a general graph. If
// a bipartite violation is detected, throw an exception
//
// We can't just iterate over the edgeSet because this can
// fail for cases like the following
//
// e1 e2 e3
// v1 ----> v2 ----> v3 <---- v4
//
// If the edges are visited in the order e1, e3, e2, then
// we might partition the vertices as ((v1, v4), (v2, v3).
// When e2 is encountered, v2 and v3 are in the same set
// and the test fails, even though there is a bipartite
// paritioning of the vertices, e.g. ((v1, v3), (v2, v4))
GraphIterator<V, E> iterator = new DepthFirstIterator<V, E>(g);
iterator.addTraversalListener(new BipartiteListener(g));
while (iterator.hasNext()) {
iterator.next();
}
}
/**
* A small, private class to walk a graph and partition it into two
classes.
*/
private final class BipartiteListener extends
TraversalListenerAdapter<V, E>
{
private final Graph<V, E> g;
public BipartiteListener(Graph<V, E> g)
{
this.g = g;
}
public void edgeTraversed(EdgeTraversalEvent<V, E> e)
{
V source = g.getEdgeSource(e.getEdge());
V target = g.getEdgeTarget(e.getEdge());
Set<V> V1 = vertexSetMapping.get(Partition.V1);
Set<V> V2 = vertexSetMapping.get(Partition.V2);
boolean V1source = V1.contains(source);
boolean V1target = V1.contains(target);
boolean V2source = V2.contains(source);
boolean V2target = V2.contains(target);
// If both vertices are in either set, throw an exception
if ((V1source && V1target) || (V2source && V2target)) {
String msg = new StringBuffer()
.append( source )
.append(" and ")
.append(target)
.append( "are in the same parition").toString();
throw new IllegalArgumentException(msg) ;
}
// Make sure that at least one of the vertices has been seen
if (!( V1source || V2source || V1target || V2target)) {
String msg = "Free edge encountered in traversal";
throw new IllegalArgumentException(msg);
}
// If only the source has been seen, assign the target to the
other set
if (V1source && !(V1target || V2target)) {
vertexSetMapping.get(Partition.V2).add(target);
}
if (V2source && !(V1target || V2target)) {
vertexSetMapping.get(Partition.V1).add(target);
}
// If only the target has been seen, assign the source to the
other set
if (V1target && !(V1source || V2source))
vertexSetMapping.get(Partition.V2).add(source);
if (V2target && !( V1source || V2source))
vertexSetMapping.get(Partition.V1).add(source);
}
public void vertexTraversed(VertexTraversalEvent<V> e)
{
V v = e.getVertex();
// If this vertex has not been encountered before, assign it
// to the first partition
if (!vertexSetMapping.get(Partition.V1).contains(v) &&
!vertexSetMapping.get(Partition.V2).contains(v))
{
vertexSetMapping.get(Partition.V1).add(v);
}
}
}
/**
* Finds the partition set that the vertex belongs to. Return null if
* the vertex does not exist.
*
* @param v Vertex
* @return
*/
private Partition vertexPartition(V v)
{
for (Map.Entry<Partition, Set<V>> entry :
vertexSetMapping.entrySet())
if (entry.getValue().contains( v ))
return entry.getKey();
return null;
}
/**
* Check that the source and target vertices are not in the same
partition
* before joining them.
*/
@Override
public E addEdge(V sourceVertex, V targetVertex)
{
if (vertexPartition(sourceVertex).equals(vertexPartition
(targetVertex))) {
return null;
}
else {
return super.addEdge(sourceVertex, targetVertex);
}
}
@Override
public boolean addEdge(V sourceVertex, V targetVertex, E e)
{
if (vertexPartition(sourceVertex).equals(vertexPartition
(targetVertex))) {
String msg = "A Bipartite graph cannot join vertices in the
same set";
throw new IllegalArgumentException(msg);
}
return super.addEdge( sourceVertex, targetVertex, e );
}
@Override
public boolean addVertex(V v)
{
return addVertex(v, Partition.V1);
}
public boolean addVertex(V v, Partition partition)
{
boolean rval = super.addVertex(v);
if (rval) {
vertexSetMapping.get(partition).add(v);
}
return rval;
}
/**
* Find a vertex in a given partition
*
* @param v
* @param partition
* @return true if the vertex is in the partition
*/
public boolean containsVertex(V v, Partition partition)
{
return vertexSetMapping.get(partition).contains(v);
}
@Override
public boolean removeVertex(V v)
{
boolean rval = super.removeVertex(v);
if (rval) {
vertexSetMapping.get(vertexPartition(v)).remove(v);
}
return rval;
}
/**
* Get the set of all vertices in one of the partitions
* @param partition
* @return a set of vertices
*/
public Set<V> vertexSet(Partition partition)
{
return Collections.unmodifiableSet(vertexSetMapping.get
(partition));
}
}
|
|
From: John V. S. <js...@gm...> - 2007-09-30 01:40:07
|
This is a maintenance release which includes a number of bugfixes and contributions which have accumulated since the 0.7.1 release. In addition, the 0.7.2 release drops support for the JRE 1.4 Retroweaver backport. The world has moved on, and the maintenance burden was no longer justifiable. If for whatever reason you are still unfortunate enough to be stuck with JRE 1.4 deployments, you can either keep using/maintaining JGraphT 0.7.1, or run retroweaver privately on 0.7.2 and beyond (this is very likely to stop working soon). As always, many thanks to all who have contributed code, tests, bugs, bugfixes, questions, and answers! A special thanks to Trevor Harmon for providing support for many incoming questions on the forums. JVS |
|
From: John V. S. <js...@gm...> - 2007-09-23 08:03:42
|
OK, all changes have been committed to Subversion. I need to clean up a bunch of Eclipse warnings, and then I'd say it's time for an 0.7.2 release. JVS gu boulmi wrote: > Seems like my zip file has been blocked... > I've renamed it with a .zip2 extension. > > > */"John V. Sichi" <js...@gm...>/* a écrit : > > Thanks, I'll check in your improvement for k-shortest, and add epsilon > as an optional parameter for Bellman-Ford. > > JVS > > gu boulmi wrote: > > Hi, > > > > Concerning my contribution, meanwhile I have noticed a special case > > where the K shortest paths algorithm performs badly but > fortunately I > > have found how to resolve it. That's why I send you those > rectifications > > (put together with the JUnit test case). > > > > Furthermore I have some remarks about the Bellman-Ford : > > > > BellmanFordPathElement#espilon > > --------------------------------------------------- > > It would be great if it could become a user-parameter (for the > moment > > the epsilon attribute is constant equal to 10-9). > > Actually, depending on the magnitude order of the cost values, the > > rouding error does not always occur at the same place beyond the > comma. > > I have personally encountered cases where I had to set the > epsilon to > > 10^-6 to avoid rounding errors. > > Because the epsilon value can not be changed by the user I was > forced to > > create new classes (copies from BellmanFordPathElement, > > BellmanFordIterator and BellmanShortestPath) allowing this change. > > > > > > Best regards, > > > > Guillaume > > > ------------------------------------------------------------------------ > Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de > mail ! <http://fr.promotions.yahoo.com/mail/nouveau_yahoomail2.html> |
|
From: John V. S. <js...@gm...> - 2007-09-10 16:38:52
|
Thanks, I'll check in your improvement for k-shortest, and add epsilon as an optional parameter for Bellman-Ford. JVS gu boulmi wrote: > Hi, > > Concerning my contribution, meanwhile I have noticed a special case > where the K shortest paths algorithm performs badly but fortunately I > have found how to resolve it. That's why I send you those rectifications > (put together with the JUnit test case). > > Furthermore I have some remarks about the Bellman-Ford : > > BellmanFordPathElement#espilon > --------------------------------------------------- > It would be great if it could become a user-parameter (for the moment > the epsilon attribute is constant equal to 10-9). > Actually, depending on the magnitude order of the cost values, the > rouding error does not always occur at the same place beyond the comma. > I have personally encountered cases where I had to set the epsilon to > 10^-6 to avoid rounding errors. > Because the epsilon value can not be changed by the user I was forced to > create new classes (copies from BellmanFordPathElement, > BellmanFordIterator and BellmanShortestPath) allowing this change. > > > Best regards, > > Guillaume |
|
From: John V. S. <js...@gm...> - 2007-07-05 09:17:08
|
I have checked Guillaume's contributions (biconnectivity/cutpoint inspection; k-shortest-paths; masked subgraphs) into Subversion. They'll be released when JGraphT 0.7.2 goes out. Guillaume, a few notes on changes I made as part of commit: - I genericized some of the classes that needed it. For future contributions, it's mandatory that they compile without warnings (for both functional code and unit tests). I've got the ant compile to pass cleanly, but still need to work through Eclipse warnings in the unit tests (since I didn't propagate the generics there yet). - In particular, clone doesn't work well with generics; I replaced that with a copy constructor pattern. - I left out the heap utility code, since it's not used by any of the new classes, and we already have an existing heap implementation with equivalent functionality. We can revisit this if there's a good reason to maintain multiple or replace. - I moved ClassBasedVertexFactory to org.jgrapht.graph as a peer to ClassBasedEdgeFactory (you had it as unit test infrastructure). - I renamed IMaskFunction to MaskFunctor to match naming conventions. - I put the copyright as France Telecom to match what you requested for earlier contributions; let me know if that is no longer correct. - I ran Jalopy to standardize formatting, and made a few other standardizations and removed the public modifier from some classes that should remain internal until they are ready for formal publication. For future contributions, please add standard JGraphT file and class headers for all files. - I deleted French-language comments (mostly in unit tests), because (a) the non-ASCII characters were giving javadoc warnings and (b) the rest of the library uses English. My apologies for the cultural imperialism. Thanks again for the great contributions; every one strengthens the library! JVS gu boulmi wrote: > Hi, > > Since last time, I've migrated to JGraphT v 0.7. > So you will find enclosed almost the same constributions that I posted > few months ago but 0.7-compliant so that it could be added to next > release without any problem. > I've added some JUnit tests and I've specified in the javadoc the > running time of the algorithms when possible. > > Zip file includes among other things: > - Element (vertex/edge) mask to allow to create a subgraph in O(1). > - BiconnectivityInspector and BlockCutpointGraph > - Algorithm for the K shortest paths > > Any feedback is welcome. > > BR, > > Guillaume > > N.B.: I've renamed the zip file with .zip2 extension so that the file > will not be blocked. > > > */"John V. Sichi" <js...@gm...>/* a écrit : > > gu boulmi wrote: > > It seems that .zip extension is blocked. That's why I've renamed > the zip > > file with .zip2 extension and I retry to send my mail above. > > Thanks, got it. I'll respond as soon as I get some time. > > I notice that you're still referring to org._3pq.jgrapht; the package > got renamed to org.jgrapht as part of the 0.7.0 release. It would help > if all files sent were baselined against the subversion head, or at > least 0.7.0, since there have been many changes. > > JVS > > > ------------------------------------------------------------------------ > Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de > mail ! <http://fr.promotions.yahoo.com/mail/nouveau_yahoomail2.html> |
|
From: John V. S. <js...@gm...> - 2007-06-05 18:56:19
|
Excellent, thanks! I'll get these integrated into Subversion. JVS gu boulmi wrote: > Hi, > > Since last time, I've migrated to JGraphT v 0.7. > So you will find enclosed almost the same constributions that I posted > few months ago but 0.7-compliant so that it could be added to next > release without any problem. > I've added some JUnit tests and I've specified in the javadoc the > running time of the algorithms when possible. > > Zip file includes among other things: > - Element (vertex/edge) mask to allow to create a subgraph in O(1). > - BiconnectivityInspector and BlockCutpointGraph > - Algorithm for the K shortest paths > > Any feedback is welcome. > > BR, > > Guillaume > > N.B.: I've renamed the zip file with .zip2 extension so that the file > will not be blocked. > > > */"John V. Sichi" <js...@gm...>/* a écrit : > > gu boulmi wrote: > > It seems that .zip extension is blocked. That's why I've renamed > the zip > > file with .zip2 extension and I retry to send my mail above. > > Thanks, got it. I'll respond as soon as I get some time. > > I notice that you're still referring to org._3pq.jgrapht; the package > got renamed to org.jgrapht as part of the 0.7.0 release. It would help > if all files sent were baselined against the subversion head, or at > least 0.7.0, since there have been many changes. > > JVS > > > ------------------------------------------------------------------------ > Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de > mail ! <http://fr.promotions.yahoo.com/mail/nouveau_yahoomail2.html> |
|
From: John V. S. <js...@gm...> - 2007-03-21 06:12:16
|
This is a maintenance release which includes a number of bugfixes and contributions which have accumulated since the 0.7.0 release. Many thanks to all who have contributed code, tests, bugs, bugfixes, questions, and answers! JVS |
5 messages has been excluded from this view by a project administrator.
