You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}

_{Dec}


2004 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(2) 
2005 
_{Jan}

_{Feb}
(1) 
_{Mar}
(5) 
_{Apr}
(1) 
_{May}

_{Jun}
(12) 
_{Jul}
(6) 
_{Aug}
(7) 
_{Sep}
(2) 
_{Oct}

_{Nov}
(1) 
_{Dec}

2006 
_{Jan}
(4) 
_{Feb}
(3) 
_{Mar}
(2) 
_{Apr}
(3) 
_{May}
(6) 
_{Jun}
(2) 
_{Jul}
(3) 
_{Aug}
(12) 
_{Sep}
(6) 
_{Oct}
(3) 
_{Nov}
(12) 
_{Dec}

2007 
_{Jan}
(6) 
_{Feb}

_{Mar}
(6) 
_{Apr}
(8) 
_{May}
(2) 
_{Jun}
(8) 
_{Jul}
(2) 
_{Aug}
(3) 
_{Sep}
(7) 
_{Oct}
(3) 
_{Nov}

_{Dec}
(1) 
2008 
_{Jan}
(11) 
_{Feb}
(4) 
_{Mar}
(8) 
_{Apr}
(3) 
_{May}
(4) 
_{Jun}
(1) 
_{Jul}

_{Aug}
(3) 
_{Sep}
(1) 
_{Oct}
(4) 
_{Nov}
(5) 
_{Dec}
(5) 
2009 
_{Jan}
(3) 
_{Feb}
(12) 
_{Mar}
(14) 
_{Apr}
(9) 
_{May}
(8) 
_{Jun}
(1) 
_{Jul}
(4) 
_{Aug}
(10) 
_{Sep}

_{Oct}
(10) 
_{Nov}

_{Dec}
(4) 
2010 
_{Jan}
(9) 
_{Feb}
(16) 
_{Mar}
(14) 
_{Apr}
(19) 
_{May}
(1) 
_{Jun}
(3) 
_{Jul}
(17) 
_{Aug}
(9) 
_{Sep}
(4) 
_{Oct}
(4) 
_{Nov}
(11) 
_{Dec}
(8) 
2011 
_{Jan}
(10) 
_{Feb}
(11) 
_{Mar}
(10) 
_{Apr}
(14) 
_{May}
(6) 
_{Jun}
(8) 
_{Jul}
(9) 
_{Aug}
(11) 
_{Sep}
(13) 
_{Oct}
(7) 
_{Nov}
(9) 
_{Dec}
(1) 
2012 
_{Jan}
(5) 
_{Feb}
(14) 
_{Mar}
(4) 
_{Apr}
(25) 
_{May}
(18) 
_{Jun}
(18) 
_{Jul}
(3) 
_{Aug}
(6) 
_{Sep}
(3) 
_{Oct}
(16) 
_{Nov}
(5) 
_{Dec}
(12) 
2013 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(14) 
_{Apr}
(34) 
_{May}
(9) 
_{Jun}
(3) 
_{Jul}
(8) 
_{Aug}

_{Sep}
(10) 
_{Oct}
(11) 
_{Nov}
(11) 
_{Dec}
(15) 
2014 
_{Jan}
(2) 
_{Feb}
(6) 
_{Mar}
(11) 
_{Apr}
(12) 
_{May}
(6) 
_{Jun}
(7) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(4) 
2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22
(1) 
23
(2) 
24
(1) 
25
(1) 
26
(1) 
27

28
(2) 
29

30




From: Joris Kinable <deus87@gm...>  20140428 20:03:55

Hi, I've never dealt with these kind of graphs so I'm not entirely sure what's supported in jgrapht. However, it wouldn't surprise me that there is no such algorithm in jgrapht. Any algorithm that computes a path from vertex x to a vertex y keeps track of the vertices it visited in order to prevent loops. What you want however is not very difficult to implement. Simply use an algorithm (like Breadth First Search) which computes all paths from x to y, thereby ignoring the loops. This gives you a list of paths. So based on your example this will give you path: A>B>C and A>. Then for each vertex with a self loop, you can generate all the variations on this path iteratively. For example if you have a loop on vertices B and A, this would result in: ABC (path you generated using BFS) Expansions: AABC AABBC ABBC AC (path you generated using BFS) Expansions: AAC Hope this helps. br, Joris On Mon, Apr 28, 2014 at 1:19 PM, raphaelrodrigues <raphaeljr28@...>wrote: > Hi, i have a Graph with loops and selfloop. The objective is to get all > the > possible paths. > > With the algorithms provide by JgraphT, i can't pass through the loops. The > algorithms pass one time in the Vertex that has loops and after that the > algoritm don't get the other possible paths from this Vertex . > > For example, if i have: > A>B > A>A > A>C > > B>A > > >From (A To C) I wanna get: > Path1: A >B>A>C > Path2: A>C > > With jgrapht i only get: > Path1: A> C > > What i wanna know is if there a possible way to find all the path with a > limit of depth maybe? Or the best way to deal with self loops and loops? > > Thank you very much! > > > >  > View this message in context: > http://jgraphtusers.107614.n3.nabble.com/Graphwithloopsandselflooptp4024920.html > Sent from the jgraphtusers mailing list archive at Nabble.com. > > >  > "Accelerate Dev Cycles with Automated CrossBrowser Testing  For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > https://lists.sourceforge.net/lists/listinfo/jgraphtusers > 
From: raphaelrodrigues <raphaeljr28@gm...>  20140428 17:19:40

Hi, i have a Graph with loops and selfloop. The objective is to get all the possible paths. With the algorithms provide by JgraphT, i can't pass through the loops. The algorithms pass one time in the Vertex that has loops and after that the algoritm don't get the other possible paths from this Vertex . For example, if i have: A>B A>A A>C B>A >From (A To C) I wanna get: Path1: A >B>A>C Path2: A>C With jgrapht i only get: Path1: A> C What i wanna know is if there a possible way to find all the path with a limit of depth maybe? Or the best way to deal with self loops and loops? Thank you very much!  View this message in context: http://jgraphtusers.107614.n3.nabble.com/Graphwithloopsandselflooptp4024920.html Sent from the jgraphtusers mailing list archive at Nabble.com. 
From: solowd <danielsolow18@gm...>  20140426 15:07:02

I'm aware that the Fibonacci heap is asymptotically better, but there's a common perception that binary heaps run faster in many applications. For example, the answers to this question <http://stackoverflow.com/questions/504823/hasanyoneactuallyimplementedafibonacciheapefficiently>; on stackoverflow. I noticed that JGraphT uses a Fibonacci heap for the ClosestFirst iterator. Has anyone done testing to compare the performance of binary heaps to the Fibonacci heap in this iterator? I'm especially interested in testing with sparse graphs (as my application doesn't care about dense graphs). I'll do some tests myself later on, but I'm curious if anyone has already thought this through. Thanks.  View this message in context: http://jgraphtusers.107614.n3.nabble.com/Fibonacciheapvsbinaryheaptp4024919.html Sent from the jgraphtusers mailing list archive at Nabble.com. 
From: Joris Kinable <deus87@gm...>  20140425 18:10:43

Hi John, Thanks for the follow up. You are right about the performance impact which occurs if additional checks are performed such as edge ownership, or edge occurrence in a graph. Perhaps we could add some assert statements to check for these issues. Doing this would not affect production code as java ignores the assert statements, whereas it would make debugging easier. This way at least some trivial cases can be verified, such as whether the edge is contained in the graph when invoking setEdgeWeight. However, this would not resolve your tricky example wrt the edge adjacency problem as graph g2 has no notion of the existence of graph g1. Wrt the documentation: depending on the quantity I would prefer to keep as much documentation in the javadoc as this is simply more convenient. However linking to an external wiki page would also be fine, especially if the amount of documentation is large. br, Joris On Wed, Apr 23, 2014 at 1:27 AM, John Sichi <jsichi@...> wrote: > Hi Joris, > > Note that this is also true for edge adjacency (even for unweighted > edges) due to the IntrusiveEdge implementation; i.e. if you add a > DefaultEdge e1 to g1 between (v1,v2), and then add e1 to g2 between > (v3,v4), e1 gets updated in both graphs (corrupting g1). > > This imperfect situation came about due to JGraphT's emphasis on > performance: it avoids the need for map lookups for traversing graphs > and accessing weights, and in the common case of no sharing (or > something like subgraph sharing where there's no discrepancy between > the two graphs), all is well. > > In other cases where edge sharability is required, it's necessary to > use your own edge class (avoiding inheritance from the Default*Edge > classes), and override the graph's get/setEdgeWeight. > > Where do you think is a good place to document this? I'm thinking > maybe a wiki page explaining the pitfalls, and then links to it from > various classes (although no matter how much documentation we do, it's > still likely that developers will overlook this). > > On Tue, Apr 22, 2014 at 8:47 PM, Joris Kinable <deus87@...> wrote: > > Hi, > > > > I've encountered some issues with edge weights which potentially could > cause > > bugs. I was wondering whether some corrections in the code are required. > > > > Take the following simple code snippet: > > > > //Define graph4, consisting of a single edge (0,1) with edge weight 10 > > WeightedGraph<Integer, DefaultWeightedEdge> graph4=new > > SimpleWeightedGraph<Integer, > > DefaultWeightedEdge>(DefaultWeightedEdge.class); > > graph4.addVertex(0); > > graph4.addVertex(1); > > DefaultWeightedEdge e1= graph4.addEdge(0, 1); > > graph4.setEdgeWeight(e1, 10); > > //Define graph5 without edges or vertices > > SimpleWeightedGraph<Integer, DefaultWeightedEdge> graph5=new > > SimpleWeightedGraph<Integer, > > DefaultWeightedEdge>(DefaultWeightedEdge.class); > > graph5.setEdgeWeight(e1, 5); > > > > System.out.println("Edge weight graph 4: "+graph4.getEdgeWeight(e1)); > > //OUTPUT: Edge weight graph 4: 5.0 > > > > Notice that jgrapht allowed me to change the weight of edge e1 in graph4 > > through graph5 which does not even contain this edge. This seems pretty > > awkward? > > > > 1. the setEdgeWeight should only work if the graph contains the edge. > > 2. I think that it would be a good idea to update the documentation of > the > > DefaultWeightedEdge, thereby emphasizing that edge weights are stored on > the > > edges, and not in the graph. Lets say you have 2 graphs, g1 and g2 both > > containing the same edge e (same object). Invoking g1.setEdgeWeight(e, > 10) > > will also change the weight of this edge in graph g2. > > > > I'm not sure how to accomplish the following: > > Given a weighted graph g1, create a subgraph g2 containing a subset of > the > > edges of g1 with *different* weights. Then for a given edge e which is > > contained in both g1 and g2, I would like to invoke: > > "Weight of e in g1: "+ g1.getEdgeWeight(e); > > "Weight of e in g2: "+ g2.getEdgeWeight(e); > > I could do something ugly by creating a mapping from edges in graph g1 to > > different edges in graph g2. Then for a given edge e in g1 I could > invoke: > > Map<DefaultWeightedEdge, DefaultWeightedEdge> edgeMapping=...; > > "Weight of e in g1: "+ g1.getEdgeWeight(e); > > "Weight of e in g2: "+ g2.getEdgeWeight(edgeMapping.get(e)); > > I would be happy to learn about cleaner methods. > > > > > > br, > > > > Joris > > > > >  > > Start Your Social Network Today  Download eXo Platform > > Build your Enterprise Intranet with eXo Platform Software > > Java Based Open Source Intranet  Social, Extensible, Cloud Ready > > Get Started Now And Turn Your Intranet Into A Collaboration Platform > > http://p.sf.net/sfu/ExoPlatform > > _______________________________________________ > > jgraphtusers mailing list > > jgraphtusers@... > > https://lists.sourceforge.net/lists/listinfo/jgraphtusers > > > 
From: Joris Kinable <deus87@gm...>  20140424 15:15:37

This reply was supposed to go over the mailing list. br, Joris  Forwarded message  From: Joris Kinable <deus87@...> Date: Wed, Apr 23, 2014 at 1:38 PM Subject: Re: [jgraphtusers] Bug in HamiltonianCycle To: Simon Heinen <simon.heinen@...> Hi Simon, In your post you have several questions. Q1: Is there also a Hamiltonian cycle algorithm implementation which produces an exact solution? No there is not. HC is an NPhard problem, meaning that it is very difficult to solve. There are entire libraries dedicated to solving just this problem, which is way beyond jgrapht. What you might want to do is to look into Concorde (http://www.math.uwaterloo.ca/tsp/concorde.html) which currently is the fastest solver. It can solve the HC problem to optimality for very large instances in reasonable time. Q2: Is there an implementation which yields better but not necessary optimal solutions? Currently not, but I've checked the implementation and there are fairly easy ways to improve the quality of the solutions with a reasonable increase in runtime. What you could do is take the solution produced by the Hamiltonian cycle implementation and run a local search on top of it, thereby performing a certain number of socalled 2opt moves ( http://en.wikipedia.org/wiki/2opt). This procedure is known to give good results in general (but obviously doesn't guarantee to find the optimal solution). What I would do is the following: 1. Use HamiltonianCycle.java to get a initial solution 2. Given the tour, find the best 2opt move out of all possible 2opt moves. If this move improves the solution, perform the move. If not, stop. This is very easy and fast to implement, especially if you are dealing with complete graphs. This would also make a nice extension of the HamiltonianCycle class implementation :). Q3: Is there a bug in the code? That's difficult to say from your example as there are so many data points. From the looks of it, the solution seems to satisfy the definition of a hamiltonian cycle: every vertex has an incoming and an outgoing edge there are no subtours e.g. it's one tour, not a collection of several tours. Check whether your solution meets these criteria. Due to the greedy nature of the algorithm the resulting tour may however be very far away from any optimal solution. In the example you showed us, performing 2opt moves will most likely provide you with the optimal solution. Note: the HamiltonianCycle class requires that your graph is complete (check this!), see comment below. Also, to guarantee a 2approximation, all edge weights must satisfy the triangle inequality. Note to developers: We should update the java doc of HamiltonianCycle.java. In the code I found this: * This method will return an approximate minimal traveling salesman tour * (hamiltonian cycle). This algorithm requires that the graph be complete * and the triangle inequality exists (if x,y,z are vertices then * d(x,y)+d(y,z)<d(x,z) for all x,y,z) then this algorithm will guarantee a * hamiltonian cycle such that the total weight of the cycle is less than or * equal to double the total weight of the optimal hamiltonian cycle. The * optimal solution is NPcomplete, so this is a decent approximation that * runs in polynomial time. This should be mentioned in the javadoc as well, preferably at the beginning. If I have a bit of spare time in the weekend I'll write a brief description for the algorithm used in the HamiltonianCycle class. There should also be a note on the runtime complexity. br, Joris On Tue, Apr 22, 2014 at 4:51 AM, Simon Heinen <simon.heinen@...>wrote: > Hello jGraphT users, > I think I found a bug in the HamiltonianCycle algorithm. I wrote it > down in detail here: > > https://github.com/jgrapht/jgrapht/issues/83 > > If someone has an idea why this happens, it would be great to get some > feedback about this. > > Thanks, > Simon > > >  > Start Your Social Network Today  Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet  Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > https://lists.sourceforge.net/lists/listinfo/jgraphtusers > 
From: John Sichi <jsichi@gm...>  20140423 05:27:25

Hi Joris, Note that this is also true for edge adjacency (even for unweighted edges) due to the IntrusiveEdge implementation; i.e. if you add a DefaultEdge e1 to g1 between (v1,v2), and then add e1 to g2 between (v3,v4), e1 gets updated in both graphs (corrupting g1). This imperfect situation came about due to JGraphT's emphasis on performance: it avoids the need for map lookups for traversing graphs and accessing weights, and in the common case of no sharing (or something like subgraph sharing where there's no discrepancy between the two graphs), all is well. In other cases where edge sharability is required, it's necessary to use your own edge class (avoiding inheritance from the Default*Edge classes), and override the graph's get/setEdgeWeight. Where do you think is a good place to document this? I'm thinking maybe a wiki page explaining the pitfalls, and then links to it from various classes (although no matter how much documentation we do, it's still likely that developers will overlook this). On Tue, Apr 22, 2014 at 8:47 PM, Joris Kinable <deus87@...> wrote: > Hi, > > I've encountered some issues with edge weights which potentially could cause > bugs. I was wondering whether some corrections in the code are required. > > Take the following simple code snippet: > > //Define graph4, consisting of a single edge (0,1) with edge weight 10 > WeightedGraph<Integer, DefaultWeightedEdge> graph4=new > SimpleWeightedGraph<Integer, > DefaultWeightedEdge>(DefaultWeightedEdge.class); > graph4.addVertex(0); > graph4.addVertex(1); > DefaultWeightedEdge e1= graph4.addEdge(0, 1); > graph4.setEdgeWeight(e1, 10); > //Define graph5 without edges or vertices > SimpleWeightedGraph<Integer, DefaultWeightedEdge> graph5=new > SimpleWeightedGraph<Integer, > DefaultWeightedEdge>(DefaultWeightedEdge.class); > graph5.setEdgeWeight(e1, 5); > > System.out.println("Edge weight graph 4: "+graph4.getEdgeWeight(e1)); > //OUTPUT: Edge weight graph 4: 5.0 > > Notice that jgrapht allowed me to change the weight of edge e1 in graph4 > through graph5 which does not even contain this edge. This seems pretty > awkward? > > 1. the setEdgeWeight should only work if the graph contains the edge. > 2. I think that it would be a good idea to update the documentation of the > DefaultWeightedEdge, thereby emphasizing that edge weights are stored on the > edges, and not in the graph. Lets say you have 2 graphs, g1 and g2 both > containing the same edge e (same object). Invoking g1.setEdgeWeight(e, 10) > will also change the weight of this edge in graph g2. > > I'm not sure how to accomplish the following: > Given a weighted graph g1, create a subgraph g2 containing a subset of the > edges of g1 with *different* weights. Then for a given edge e which is > contained in both g1 and g2, I would like to invoke: > "Weight of e in g1: "+ g1.getEdgeWeight(e); > "Weight of e in g2: "+ g2.getEdgeWeight(e); > I could do something ugly by creating a mapping from edges in graph g1 to > different edges in graph g2. Then for a given edge e in g1 I could invoke: > Map<DefaultWeightedEdge, DefaultWeightedEdge> edgeMapping=...; > "Weight of e in g1: "+ g1.getEdgeWeight(e); > "Weight of e in g2: "+ g2.getEdgeWeight(edgeMapping.get(e)); > I would be happy to learn about cleaner methods. > > > br, > > Joris > >  > Start Your Social Network Today  Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet  Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > https://lists.sourceforge.net/lists/listinfo/jgraphtusers > 
From: Joris Kinable <deus87@gm...>  20140423 03:47:10

Hi, I've encountered some issues with edge weights which potentially could cause bugs. I was wondering whether some corrections in the code are required. Take the following simple code snippet: //Define graph4, consisting of a single edge (0,1) *with edge weight 10* WeightedGraph<Integer, DefaultWeightedEdge> graph4=new SimpleWeightedGraph<Integer, DefaultWeightedEdge>(DefaultWeightedEdge.class); graph4.addVertex(0); graph4.addVertex(1); DefaultWeightedEdge e1= graph4.addEdge(0, 1); graph4.setEdgeWeight(e1, *10*); //Define graph5 without edges or vertices SimpleWeightedGraph<Integer, DefaultWeightedEdge> graph5=new SimpleWeightedGraph<Integer, DefaultWeightedEdge>(DefaultWeightedEdge.class); graph5.setEdgeWeight(e1, 5); System.out.println("Edge weight graph 4: "+graph4.getEdgeWeight(e1)); *//OUTPUT: Edge weight graph 4: 5.0* Notice that jgrapht allowed me to change the weight of edge e1 in graph4 through graph5 which does not even contain this edge. This seems pretty awkward? 1. the setEdgeWeight should only work if the graph contains the edge. 2. I think that it would be a good idea to update the documentation of the DefaultWeightedEdge, thereby emphasizing that edge weights are stored on the edges, and not in the graph. Lets say you have 2 graphs, g1 and g2 both containing the same edge e (same object). Invoking g1.setEdgeWeight(e, 10) will also change the weight of this edge in graph g2. I'm not sure how to accomplish the following: Given a weighted graph g1, create a subgraph g2 containing a subset of the edges of g1 with *different* weights. Then for a given edge e which is contained in both g1 and g2, I would like to invoke: "Weight of e in g1: "+ g1.getEdgeWeight(e); "Weight of e in g2: "+ g2.getEdgeWeight(e); I could do something ugly by creating a mapping from edges in graph g1 to different edges in graph g2. Then for a given edge e in g1 I could invoke: Map<DefaultWeightedEdge, DefaultWeightedEdge> edgeMapping=...; "Weight of e in g1: "+ g1.getEdgeWeight(e); "Weight of e in g2: "+ g2.getEdgeWeight(edgeMapping.get(e)); I would be happy to learn about cleaner methods. br, Joris 
From: Simon Heinen <simon.heinen@gm...>  20140422 08:52:11

Hello jGraphT users, I think I found a bug in the HamiltonianCycle algorithm. I wrote it down in detail here: https://github.com/jgrapht/jgrapht/issues/83 If someone has an idea why this happens, it would be great to get some feedback about this. Thanks, Simon 
From: Rikless <eric.mermet@gm...>  20140401 17:58:12

Thanks a lot !  View this message in context: http://jgraphtusers.107614.n3.nabble.com/LabelEdgeExampletp4024899p4024913.html Sent from the jgraphtusers mailing list archive at Nabble.com. 
From: Sebastian Müller <woowlegave@gm...>  20140401 12:00:17

Wolfram MathWorld explains it well: " Some references require that multigraphs possess no graph loops, some explicitly allow them, and yet others do not include any explicit allowance or disallowance. Worse still, Tutte uses the term "multigraph" to mean a graph containing either loops or multiple edges. As a result of these many ambiguities, use of the term "multigraph" should be deprecated, or at the very least used with extreme caution. " http://mathworld.wolfram.com/Multigraph.html Sebastian On 04/01/2014 01:54 PM, Szabolcs Besenyei wrote: > Hi! > > A multidigraph by definition is a directed graph which is permitted to > have multiple edges with the same source and target nodes/. > / > It can also allow loops, however some like to call these > *pseudographs*/,/ reserving the term multigraph for the case with no > loops. > Jgrapht is implemented to preseve this distinction. > / > / > So to answer your question in short, DirectedPseudograph is the > structure you are looking for. > > Szabolcs > // > > > 20140401 0:06 GMT+02:00 Rikless <eric.mermet@... > <mailto:eric.mermet@...>>: > > Hi, > > I come back on this post because i had the same problem on an old > algorithm > using a DirectedWeightedMultigraph structure. > > I know that there is loops on my data, that's why i choosed this > structure. > As mentionned in the javadoc : > *DirectedMultigraph* (used by Patricia) : A directed multigraph is a > nonsimple directed graph in which loops and multiple edges > between any two > vertices are permitted. > *DirectedWeightedMultigraph* : A directed weighted multigraph is a > nonsimple directed graph in which loops and multiple edges > between any two > vertices are permitted, and edges have weights. > > I think something have changed since version 0.9.0. > > Any idea ? > What is the structure i can use with loops and multiple edges ? > > Rik > > > > > >  > View this message in context: > http://jgraphtusers.107614.n3.nabble.com/LabelEdgeExampletp4024899p4024909.html > Sent from the jgraphtusers mailing list archive at Nabble.com. > >  > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > <mailto:jgraphtusers@...> > https://lists.sourceforge.net/lists/listinfo/jgraphtusers > > > > >  > > > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > https://lists.sourceforge.net/lists/listinfo/jgraphtusers 
From: Sebastian Müller <woowlegave@gm...>  20140401 11:55:33

I believe there was a discussion about this last year. See change here: https://github.com/jgrapht/jgrapht/commit/8fe299c38648acac55e40bd47498a08269e01f74 You can use a DirectedPseudograph in your case. http://jgrapht.org/javadoc/index.html?org/jgrapht/graph/DirectedWeightedPseudograph.html Sebastian On 04/01/2014 12:06 AM, Rikless wrote: > Hi, > > I come back on this post because i had the same problem on an old algorithm > using a DirectedWeightedMultigraph structure. > > I know that there is loops on my data, that's why i choosed this structure. > As mentionned in the javadoc : > *DirectedMultigraph* (used by Patricia) : A directed multigraph is a > nonsimple directed graph in which loops and multiple edges between any two > vertices are permitted. > *DirectedWeightedMultigraph* : A directed weighted multigraph is a > nonsimple directed graph in which loops and multiple edges between any two > vertices are permitted, and edges have weights. > > I think something have changed since version 0.9.0. > > Any idea ? > What is the structure i can use with loops and multiple edges ? > > Rik > > > > > >  > View this message in context: http://jgraphtusers.107614.n3.nabble.com/LabelEdgeExampletp4024899p4024909.html > Sent from the jgraphtusers mailing list archive at Nabble.com. > >  > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > https://lists.sourceforge.net/lists/listinfo/jgraphtusers 
From: Szabolcs Besenyei <besza.elte@gm...>  20140401 11:54:19

Hi! A multidigraph by definition is a directed graph which is permitted to have multiple edges with the same source and target nodes *.* It can also allow loops, however some like to call these *pseudographs**,*reserving the term multigraph for the case with no loops. Jgrapht is implemented to preseve this distinction. So to answer your question in short, DirectedPseudograph is the structure you are looking for. Szabolcs 20140401 0:06 GMT+02:00 Rikless <eric.mermet@...>: > Hi, > > I come back on this post because i had the same problem on an old algorithm > using a DirectedWeightedMultigraph structure. > > I know that there is loops on my data, that's why i choosed this structure. > As mentionned in the javadoc : > *DirectedMultigraph* (used by Patricia) : A directed multigraph is a > nonsimple directed graph in which loops and multiple edges between any two > vertices are permitted. > *DirectedWeightedMultigraph* : A directed weighted multigraph is a > nonsimple directed graph in which loops and multiple edges between any two > vertices are permitted, and edges have weights. > > I think something have changed since version 0.9.0. > > Any idea ? > What is the structure i can use with loops and multiple edges ? > > Rik > > > > > >  > View this message in context: > http://jgraphtusers.107614.n3.nabble.com/LabelEdgeExampletp4024899p4024909.html > Sent from the jgraphtusers mailing list archive at Nabble.com. > > >  > _______________________________________________ > jgraphtusers mailing list > jgraphtusers@... > https://lists.sourceforge.net/lists/listinfo/jgraphtusers > 