Re: [gephi-dev] Generators

[Sébastien Heymann]

That's cool!

Maybe you should find a way to create a unified GUI for each generator. For instance the user select "Barabási–Albert" item on the Generator menu, then choose a version between the 4 available as 4 different tabs in the window.

What do you think about it?

Seb

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Hi,

I need to make some generators for my work at the university, so I'll create a branch for this purpose. Probably I'll commit them tomorrow.

For now I need a subset of generators presented in my post written before GSoC:

a) Erdős-Rényi model in two versions G(n, p) and G(n, m)

b) Alpha and Beta models of Watts and Strogatz (from what I can see Mathieu implemented some generator of this model which takes other parameters I plan to use ;) - so we will have got three different generators :P)

c) Kleinberg model

d) Barabási–Albert model in 4 versions: basic, generalized generator with probabilities of adding new edges and rewiring existing ones, simplified models: A (uniform attachment) and B (no growth)

In the close future I also plan to add HierarchicalGraph generator.

_______________________________________________
gephi-dev mailing list
geph...@lists.gephi.org
http://gephi.org/mailman/listinfo/gephi-dev

[Cezary Bartosiak]

No problem - I'm planning to work on these generators in January since I need them for my another experimental branch (spread-simulator - it is for the experiments at my university, it's rather not going to be published, I wanted to use the toolkit, but I need visualization, that's why I develop it this way :P). Anyway I'll work on the generators soon (in January), so then I'll do all these things you want :)

On 20 December 2010 01:20, Mathieu Bastian <mathieu...@gmail.com> wrote:

Hi Cezary,

Thought it is an awesome work, I think the new long list of generators in the UI could make new users feel a bit lost. That's why I think it would be better to have these 'scientific' generators as a plug-in and keep the list very simple, with Random Graph.

There is a new branch
https://code.launchpad.net/~gephi.team/gephi/generators

Could you please create a new module for that, ComplexGenerator? ScienceGenerators?

As for other plug-ins that have a UI module, the best would be to create a third 'empty' module that depends on both UI and business modules, with the description. I also count on you to document and upload these candies on the plug-in center :-) Many researchers will be happy about this new plug-in.

Mathieu

On Sat, Dec 18, 2010 at 2:43 PM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

OK, fixed. Unfortunately my i7 processor can't process YifanHu's algorithm in reasonable time for 62500 nodes. But for 10k it's ok :P

On 18 December 2010 14:58, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Oh, progress uses integer. I'll fix it.

On 18 December 2010 07:31, Mathieu Bastian <mathieu...@gmail.com> wrote:

Hi Cezary, I merged the new generators into the trunk. The code looks clean and the validators for the UI is great! Congrats.

Small exception when running Kleinberg with 250 - 1 - 0 - 0

java.lang.IllegalArgumentException: Cannot decrease processed workunit count (-1) to lower value than before (0)
    at org.netbeans.modules.progress.spi.InternalHandle.progress(InternalHandle.java:260)
    at org.netbeans.api.progress.ProgressHandle.progress(ProgressHandle.java:174)
    at org.netbeans.api.progress.ProgressHandle.progress(ProgressHandle.java:156)
    at org.gephi.desktop.progress.ProgressTicketImpl.progress(ProgressTicketImpl.java:74)
    at org.gephi.desktop.progress.ProgressTicketImpl.progress(ProgressTicketImpl.java:61)
    at org.gephi.utils.progress.Progress.progress(Progress.java:46)
    at org.gephi.io.generator.plugin.Kleinberg.generate(Kleinberg.java:109)
...

ps: The effect with Yifan Hu multilevel is not bad either :-)

On Wed, Dec 15, 2010 at 6:38 PM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

OK, it's finished and waiting for the review ;)

On 15 December 2010 17:17, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

I have provided some changes:

* changed EdgeDefault to undirected in most generators (excepting Kleinberg)

* removed the old Watts-Strogatz beta model generator and added the new one

I removed the old Watts-Strogatz generator, because it generated a beta model (which I create in another generator) and I discovered it "too late". Anyway, I would like to create also alpha model and write some hierarchical generator (probably balanced tree generator because it meets my needs). When I finish I'll let you know.

On 15 December 2010 14:31, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Yes, you can add this line:
container.setEdgeDefault(EdgeDefault.UNDIRECTED)

So, for instance, container.edgeExists(nodes[i], nodes[j]) should return true even if I add edge this way: edge.setSource(nodes[j]), edge.setTarget(nodes[i])?

On 13 December 2010 07:57, Mathieu Bastian <mathieu...@gmail.com> wrote:

On Sun, Dec 12, 2010 at 7:41 PM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Merging with 0.7 works perfectly :P

By the way:

1. Is it enough to change a version number for Generator Plugin and Generator Plugin UI modules to let people get updates? (of course I would do it after I finish and my branch should be merged firstly :P)

Yes
 

2. Is it possible to generate undirected edges? And, even if they are directed, if I set network interpretation to undirected (in metrics) all edges are treated as undirected, right?

Yes, you can add this line:
container.setEdgeDefault(EdgeDefault.UNDIRECTED)
 

3. To sum up generators, we need to develop the following things (in the future :P):

a) some small graph structure to make generators more optimal (and easier to implement :P)

b) better UIs (with descriptions and so on)

Agree
 

On 13 December 2010 04:23, Mathieu Bastian <mathieu...@gmail.com> wrote:

Awesome! That looks great...

Regarding the repository format, Sebastien may have better explanation but it's probably because the trunk is now from the 0.8 branch, which has been created recently and therefore with the latest bazaar repository version. Did you tried to merge with the 0.7 branch "bzr pull lp:gephi/0.7" ?

On Sun, Dec 12, 2010 at 7:08 PM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Hi,

I have implemented all generators mentioned earlier excepting Watts-Strogatz ones. I'll implement them as soon as possible. I pushed them into repository. Unfortunately I can't merge with trunk because there is another repository format (mine is KnitPack). Could you do something with it Sébastien? You probably need to upgrade repo format.

Some info:

1. These generators could be faster not only because of optimizations, but also by reducing complexity. Unfortunately now I don't have time to play with it :P Anyway they are good enough for my experiments.

2. Some of them may seem to work "strangely". For instance BA Simplified B model generator for complete graphs will be very slow, much slower than ER model generators because it is created for generating network whose degree distribution follows a power law, so if you can see 99 % for a long time in case of very dense or even complete graphs - it's normal :P

3. Create Kleinberg graph with such parameters (n = 25, p = 1, q = 0, r = 0) and then fire some Yifan-Hu layout algorithm (if it stops run it again until it creates a grid). The effect is very nice :P

PS. As for dynamic-attr-stats branch I will work on it after I finish similarity-plugin branch. It will take probably 3 weeks until I do it. So lacking dynamic statistics will be created (probably) in January.

On 11 December 2010 17:27, Sébastien Heymann <sebastie...@gephi.org> wrote:

Classic :P

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Maybe in the future because of time constraints :P

[Cezary Bartosiak]

I'm going to release them as soon as possible. But first I need to finish
things connected with my thesis. I mean, it's ready, but I must do some
formalities (printing etc.).

Sorry for the lateness, I would like write some docs for the generators,
that's why I'm waiting with the release :P

On 12 January 2011 17:36, Mathieu Bastian <mathieu...@gmail.com> wrote:

> Hello Cezary,
>
> some updates on packaging these new awesome set of generators?
>
> Mathieu
>
> On Sun, Dec 19, 2010 at 4:41 PM, Cezary Bartosiak

[Sébastien Heymann]

Classic :P

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Maybe in the future because of time constraints :P

On 11 December 2010 16:56, Sébastien Heymann <sebastie...@gephi.org> wrote:

[Cezary Bartosiak]

Hi guys,

I'm currently improving my generators plugin. I would like to add a functionality, that will let us create a list of generators that will generate a graph in a fixed order (and adds timestapms to nodes so we can show a process of graph's creation using timeline). However I have got some problem. Namely I don't know how to get nodes/edges added to ContainerLoader earlier. How can do it? I can't locate any method that would help me.

Cheers,

Cezary

[Mathieu Bastian]

Hi,

I have implemented all generators mentioned earlier excepting Watts-Strogatz ones. I'll implement them as soon as possible. I pushed them into repository. Unfortunately I can't merge with trunk because there is another repository format (mine is KnitPack). Could you do something with it Sébastien? You probably need to upgrade repo format.

Some info:

1. These generators could be faster not only because of optimizations, but also by reducing complexity. Unfortunately now I don't have time to play with it :P Anyway they are good enough for my experiments.

2. Some of them may seem to work "strangely". For instance BA Simplified B model generator for complete graphs will be very slow, much slower than ER model generators because it is created for generating network whose degree distribution follows a power law, so if you can see 99 % for a long time in case of very dense or even complete graphs - it's normal :P

3. Create Kleinberg graph with such parameters (n = 25, p = 1, q = 0, r = 0) and then fire some Yifan-Hu layout algorithm (if it stops run it again until it creates a grid). The effect is very nice :P

PS. As for dynamic-attr-stats branch I will work on it after I finish similarity-plugin branch. It will take probably 3 weeks until I do it. So lacking dynamic statistics will be created (probably) in January.

On 11 December 2010 17:27, Sébastien Heymann <sebastie...@gephi.org> wrote:

[Mathieu Bastian]

[Cezary Bartosiak]

Hi,

I have implemented all generators mentioned earlier excepting Watts-Strogatz ones. I'll implement them as soon as possible. I pushed them into repository. Unfortunately I can't merge with trunk because there is another repository format (mine is KnitPack). Could you do something with it Sébastien? You probably need to upgrade repo format.

Some info:

1. These generators could be faster not only because of optimizations, but also by reducing complexity. Unfortunately now I don't have time to play with it :P Anyway they are good enough for my experiments.

2. Some of them may seem to work "strangely". For instance BA Simplified B model generator for complete graphs will be very slow, much slower than ER model generators because it is created for generating network whose degree distribution follows a power law, so if you can see 99 % for a long time in case of very dense or even complete graphs - it's normal :P

3. Create Kleinberg graph with such parameters (n = 25, p = 1, q = 0, r = 0) and then fire some Yifan-Hu layout algorithm (if it stops run it again until it creates a grid). The effect is very nice :P

PS. As for dynamic-attr-stats branch I will work on it after I finish similarity-plugin branch. It will take probably 3 weeks until I do it. So lacking dynamic statistics will be created (probably) in January.

On 11 December 2010 17:27, Sébastien Heymann <sebastie...@gephi.org> wrote:

[Cezary Bartosiak]

>
> more optimal
>

I mean close to optimum :)

On 13 December 2010 04:41, Cezary Bartosiak <cezary.b...@gmail.com>wrote:

> Merging with 0.7 works perfectly :P
>
> By the way:
>
> 1. Is it enough to change a version number for Generator Plugin and
> Generator Plugin UI modules to let people get updates? (of course I would do
> it after I finish and my branch should be merged firstly :P)
>

> 2. Is it possible to generate undirected edges? And, even if they are
> directed, if I set network interpretation to undirected (in metrics) all
> edges are treated as undirected, right?
>

> 3. To sum up generators, we need to develop the following things (in the
> future :P):
>
> a) some small graph structure to make generators more optimal (and easier
> to implement :P)
>
> b) better UIs (with descriptions and so on)
>

[Cezary Bartosiak]

Merging with 0.7 works perfectly :P

By the way:

1. Is it enough to change a version number for Generator Plugin and
Generator Plugin UI modules to let people get updates? (of course I would do
it after I finish and my branch should be merged firstly :P)

2. Is it possible to generate undirected edges? And, even if they are
directed, if I set network interpretation to undirected (in metrics) all
edges are treated as undirected, right?

3. To sum up generators, we need to develop the following things (in the
future :P):

a) some small graph structure to make generators more optimal (and easier to
implement :P)

b) better UIs (with descriptions and so on)

On 13 December 2010 04:23, Mathieu Bastian <mathieu...@gmail.com>wrote:

> Awesome! That looks great...
>
> Regarding the repository format, Sebastien may have better explanation but
> it's probably because the trunk is now from the 0.8 branch, which has been

> created recently and therefore with the latest bazaar repository version.
> Did you tried to merge with the 0.7 branch "bzr pull lp:gephi/0.7" ?
>
>

[Mathieu Bastian]

Hello Cezary,

some updates on packaging these new awesome set of generators?

Mathieu

[Cezary Bartosiak]

Maybe in the future because of time constraints :P

On 11 December 2010 16:56, Sébastien Heymann <sebastie...@gephi.org> wrote:

[Mathieu Bastian]

Awesome! That looks great...

Regarding the repository format, Sebastien may have better explanation but
it's probably because the trunk is now from the 0.8 branch, which has been
created recently and therefore with the latest bazaar repository version.
Did you tried to merge with the 0.7 branch "bzr pull lp:gephi/0.7" ?

[Cezary Bartosiak]

OK, I've got a complete schedule for February (including my thesis and other high priority, time consuming things). Unfortunately it follows that generators will be published on ~13.02.2011. As I wrote earlier I must write a documentation and I want to add some generators. I have got ideas for extending existing ones as well.

If you think it's too late I can publish them now, but without docs (I don't find it a good idea)... so, what do you think?

[Cezary Bartosiak]

[Cezary Bartosiak]

OK, it's finished and waiting for the review ;)

On 15 December 2010 17:17, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

I have provided some changes:

* changed EdgeDefault to undirected in most generators (excepting Kleinberg)

* removed the old Watts-Strogatz beta model generator and added the new one

I removed the old Watts-Strogatz generator, because it generated a beta model (which I create in another generator) and I discovered it "too late". Anyway, I would like to create also alpha model and write some hierarchical generator (probably balanced tree generator because it meets my needs). When I finish I'll let you know.

On 15 December 2010 14:31, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Yes, you can add this line:
container.setEdgeDefault(EdgeDefault.UNDIRECTED)

So, for instance, container.edgeExists(nodes[i], nodes[j]) should return true even if I add edge this way: edge.setSource(nodes[j]), edge.setTarget(nodes[i])?

On 13 December 2010 07:57, Mathieu Bastian <mathieu...@gmail.com> wrote:

Awesome! That looks great...

Regarding the repository format, Sebastien may have better explanation but it's probably because the trunk is now from the 0.8 branch, which has been created recently and therefore with the latest bazaar repository version. Did you tried to merge with the 0.7 branch "bzr pull lp:gephi/0.7" ?

On Sun, Dec 12, 2010 at 7:08 PM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Hi,

I have implemented all generators mentioned earlier excepting Watts-Strogatz ones. I'll implement them as soon as possible. I pushed them into repository. Unfortunately I can't merge with trunk because there is another repository format (mine is KnitPack). Could you do something with it Sébastien? You probably need to upgrade repo format.

Some info:

1. These generators could be faster not only because of optimizations, but also by reducing complexity. Unfortunately now I don't have time to play with it :P Anyway they are good enough for my experiments.

2. Some of them may seem to work "strangely". For instance BA Simplified B model generator for complete graphs will be very slow, much slower than ER model generators because it is created for generating network whose degree distribution follows a power law, so if you can see 99 % for a long time in case of very dense or even complete graphs - it's normal :P

3. Create Kleinberg graph with such parameters (n = 25, p = 1, q = 0, r = 0) and then fire some Yifan-Hu layout algorithm (if it stops run it again until it creates a grid). The effect is very nice :P

PS. As for dynamic-attr-stats branch I will work on it after I finish similarity-plugin branch. It will take probably 3 weeks until I do it. So lacking dynamic statistics will be created (probably) in January.

On 11 December 2010 17:27, Sébastien Heymann <sebastie...@gephi.org> wrote:

Classic :P

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Maybe in the future because of time constraints :P

On 11 December 2010 16:56, Sébastien Heymann <sebastie...@gephi.org> wrote:

That's cool!

Maybe you should find a way to create a unified GUI for each generator. For instance the user select "Barabási–Albert" item on the Generator menu, then choose a version between the 4 available as 4 different tabs in the window.

What do you think about it?

Seb

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Hi,

[Cezary Bartosiak]

Well,

I count it manually :P But I'm still interested if there is a better way.

On 11 December 2010 19:51, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Hi,

I've got some problem. Some algorithms require to use information like degrees of nodes that have been added in previous steps or smth like that. Since I use only NodeDrafts and EdgeDrafts I can't get such information. What should I do? Should I use specific implementations like HierarchicalUndirectedGraphImpl (additional module dependency which is rather not good idea...)?

[Cezary Bartosiak]

OK, fixed. Unfortunately my i7 processor can't process YifanHu's algorithm in reasonable time for 62500 nodes. But for 10k it's ok :P

On 18 December 2010 14:58, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Oh, progress uses integer. I'll fix it.

On 18 December 2010 07:31, Mathieu Bastian <mathieu...@gmail.com> wrote:

Hi Cezary, I merged the new generators into the trunk. The code looks clean and the validators for the UI is great! Congrats.

Small exception when running Kleinberg with 250 - 1 - 0 - 0

java.lang.IllegalArgumentException: Cannot decrease processed workunit count (-1) to lower value than before (0)
    at org.netbeans.modules.progress.spi.InternalHandle.progress(InternalHandle.java:260)
    at org.netbeans.api.progress.ProgressHandle.progress(ProgressHandle.java:174)
    at org.netbeans.api.progress.ProgressHandle.progress(ProgressHandle.java:156)
    at org.gephi.desktop.progress.ProgressTicketImpl.progress(ProgressTicketImpl.java:74)
    at org.gephi.desktop.progress.ProgressTicketImpl.progress(ProgressTicketImpl.java:61)
    at org.gephi.utils.progress.Progress.progress(Progress.java:46)
    at org.gephi.io.generator.plugin.Kleinberg.generate(Kleinberg.java:109)
...

ps: The effect with Yifan Hu multilevel is not bad either :-)

[Mathieu Bastian]

Hi Cezary, I merged the new generators into the trunk. The code looks clean and the validators for the UI is great! Congrats.

Small exception when running Kleinberg with 250 - 1 - 0 - 0

java.lang.IllegalArgumentException: Cannot decrease processed workunit count (-1) to lower value than before (0)
    at org.netbeans.modules.progress.spi.InternalHandle.progress(InternalHandle.java:260)
    at org.netbeans.api.progress.ProgressHandle.progress(ProgressHandle.java:174)
    at org.netbeans.api.progress.ProgressHandle.progress(ProgressHandle.java:156)
    at org.gephi.desktop.progress.ProgressTicketImpl.progress(ProgressTicketImpl.java:74)
    at org.gephi.desktop.progress.ProgressTicketImpl.progress(ProgressTicketImpl.java:61)
    at org.gephi.utils.progress.Progress.progress(Progress.java:46)
    at org.gephi.io.generator.plugin.Kleinberg.generate(Kleinberg.java:109)
...

ps: The effect with Yifan Hu multilevel is not bad either :-)

[Cezary Bartosiak]

[Cezary Bartosiak]

I have provided some changes:

* changed EdgeDefault to undirected in most generators (excepting Kleinberg)

* removed the old Watts-Strogatz beta model generator and added the new one

I removed the old Watts-Strogatz generator, because it generated a beta model (which I create in another generator) and I discovered it "too late". Anyway, I would like to create also alpha model and write some hierarchical generator (probably balanced tree generator because it meets my needs). When I finish I'll let you know.

On 15 December 2010 14:31, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Yes, you can add this line:
container.setEdgeDefault(EdgeDefault.UNDIRECTED)

So, for instance, container.edgeExists(nodes[i], nodes[j]) should return true even if I add edge this way: edge.setSource(nodes[j]), edge.setTarget(nodes[i])?

On 13 December 2010 07:57, Mathieu Bastian <mathieu...@gmail.com> wrote:

Awesome! That looks great...

Regarding the repository format, Sebastien may have better explanation but it's probably because the trunk is now from the 0.8 branch, which has been created recently and therefore with the latest bazaar repository version. Did you tried to merge with the 0.7 branch "bzr pull lp:gephi/0.7" ?

On Sun, Dec 12, 2010 at 7:08 PM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

Hi,

I have implemented all generators mentioned earlier excepting Watts-Strogatz ones. I'll implement them as soon as possible. I pushed them into repository. Unfortunately I can't merge with trunk because there is another repository format (mine is KnitPack). Could you do something with it Sébastien? You probably need to upgrade repo format.

Some info:

1. These generators could be faster not only because of optimizations, but also by reducing complexity. Unfortunately now I don't have time to play with it :P Anyway they are good enough for my experiments.

2. Some of them may seem to work "strangely". For instance BA Simplified B model generator for complete graphs will be very slow, much slower than ER model generators because it is created for generating network whose degree distribution follows a power law, so if you can see 99 % for a long time in case of very dense or even complete graphs - it's normal :P

3. Create Kleinberg graph with such parameters (n = 25, p = 1, q = 0, r = 0) and then fire some Yifan-Hu layout algorithm (if it stops run it again until it creates a grid). The effect is very nice :P

PS. As for dynamic-attr-stats branch I will work on it after I finish similarity-plugin branch. It will take probably 3 weeks until I do it. So lacking dynamic statistics will be created (probably) in January.

On 11 December 2010 17:27, Sébastien Heymann <sebastie...@gephi.org> wrote:

Classic :P

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Maybe in the future because of time constraints :P

On 11 December 2010 16:56, Sébastien Heymann <sebastie...@gephi.org> wrote:

That's cool!

Maybe you should find a way to create a unified GUI for each generator. For instance the user select "Barabási–Albert" item on the Generator menu, then choose a version between the 4 available as 4 different tabs in the window.

What do you think about it?

Seb

2010/12/11 Cezary Bartosiak <cezary.b...@gmail.com>

Hi,

[Cezary Bartosiak]

Oh, progress uses integer. I'll fix it.

On 18 December 2010 07:31, Mathieu Bastian <mathieu...@gmail.com> wrote:

[Cezary Bartosiak]

It's a nice idea, but for the future (time constraints :/). For now I solved my problem (fortunately it was easy to do without worsening complexity). But I can imagine algorithms that would need more complex info that would require some graph structure. So we should have this on our TODO list.

On 11 December 2010 20:07, Mathieu Bastian <mathieu...@gmail.com> wrote:

This is indeed a problem, the current NodeDraft and EdgeDraft are quite limited. When I designed this I had in mind basic importers and so onll get/set support. So its not possible to get the degree or the edges for a particular node, which is often needed for generators. It would be worthed to redesign these classes and have something closer from what you can get in Graph API. It's also important to be able to remove elements, this is currently not possible. The class to change is the Import Container. Instead of having simple lists for nodes and edges, we would build a small graph structurem with hashmaps for instance. What do ou think?

_______________________________________________
gephi-dev mailing list
geph...@lists.gephi.org
http://gephi.org/mailman/listinfo/gephi-dev

[Mathieu Bastian]

This is indeed a problem, the current NodeDraft and EdgeDraft are quite limited. When I designed this I had in mind basic importers and so onll get/set support. So its not possible to get the degree or the edges for a particular node, which is often needed for generators. It would be worthed to redesign these classes and have something closer from what you can get in Graph API. It's also important to be able to remove elements, this is currently not possible. The class to change is the Import Container. Instead of having simple lists for nodes and edges, we would build a small graph structurem with hashmaps for instance. What do ou think?

On Sat, Dec 11, 2010 at 11:01 AM, Cezary Bartosiak <cezary.b...@gmail.com> wrote:

[Cezary Bartosiak]

>
> Yes, you can add this line:
> container.setEdgeDefault(EdgeDefault.UNDIRECTED)
>

So, for instance, container.edgeExists(nodes[*i*], nodes[*j*]) should return
true even if I add edge this way: edge.setSource(nodes[*j*]),
edge.setTarget(nodes[*i*])?

On 13 December 2010 07:57, Mathieu Bastian <mathieu...@gmail.com>wrote:

>
>

>>> version. Did you tried to merge with the 0.7 branch "bzr pull lp:gephi/0.7"
>>> ?
>>>
>>>