A new nx_pylab function...

197 views
Skip to first unread message

Ben Edwards

unread,
Aug 28, 2010, 3:26:19 PM8/28/10
to networkx...@googlegroups.com
While playing around with some code for this ticket


I also came across this ticket:


And so began fiddling to try to get both to work. I think I have a pretty good implementation that uses patches for both the nodes and the edges, rather than scatter plot and line collections, and now the draw node and draw edges functions return dictionaries of patches so you can modify each node and edge afterwards if you would like. I also tried to clean up the code a bit and functionize some repeated code. Also addressing ticket 293, I wrote an is_weighted function to see if a graph is weighted, it could easily become part of the Graph class. This I think gives a little finer control over the properties of both nodes and edges. I thought I might post the function to the list to see if everyone could test it rather than just putting a huge patch to the trac server. I know it works on the gallery graphs, giving the same results except I can't tell if it works on the chess_masters.py, degree_histogram.py, and labels_and_colors.py, because I get strange unicode errors for both the old function and this one. This could have something to do with matplotlib, but I don't know. All that said, here is what is new and different

New:
Actual arrows drawn on DiGraphs
Can control arrow style, and edge style, including the ability to have arced edges, check matplotlib's FancyArrowPatch
Can use edge weights to scale thickness or edge color
Can pass keyed dictionary for edge_color and node_color
Cleaner code (somewhat)

Different:
Node size should be the same, as I do a conversion in the function. However, size is now absolute to the figure not just the axis (I am not sure how scatter does this) so in figures with subplots you have to scale up the nodes size. The factor is the number of subplot sections squared. So the examples four_grids.py should now have node sizes 4800, 0, 4000, 320. Also if you plot interactively, zooming the node or the entire figure actually zooms the node size instead of keeping the same approximate node size. I don't know if this is desirable or not.

Also it seems to be a little slower. I am testing on a pretty fast machine, so if its a significant slow down for anyone  I might have to reconsider how I do some things. 

Attached is the new function, as well as two tests functions for the new features. If anyone would like to test it and see if there are any bugs that would be great.

Ben
nx_pylab.py
color_weight.py
color_weight.png
width_weight.png
width_weight.py

Ben Edwards

unread,
Aug 28, 2010, 8:30:26 PM8/28/10
to networkx-discuss
Had a problem, with my matplotlib install, but I fixed it with the new
version, all gallery images look the same with the new function,
except for the better looking arrows.
>  nx_pylab.py
> 44KViewDownload
>
>  color_weight.py
> < 1KViewDownload
>
>  color_weight.png
> 52KViewDownload
>
>  width_weight.png
> 55KViewDownload
>
>  width_weight.py
> < 1KViewDownload

Jason Grout

unread,
Aug 28, 2010, 9:47:25 PM8/28/10
to networkx...@googlegroups.com
On 8/28/10 2:26 PM, Ben Edwards wrote:

> Node size should be the same, as I do a conversion in the function. However,
> size is now absolute to the figure not just the axis (I am not sure how
> scatter does this)


There are several ways to do something like this (one being use
scatterplot :). In fact, this just came up the other day on the
matplotlib mailing list. See


http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTim6ZnGiOV1RTRBz0uBMF5y67xyrDp%2BkVSCBtkrB%40mail.gmail.com&forum_name=matplotlib-users

so in figures with subplots you have to scale up the
> nodes size. The factor is the number of subplot sections squared. So the
> examples four_grids.py should now have node sizes 4800, 0, 4000, 320. Also
> if you plot interactively, zooming the node or the entire figure actually
> zooms the node size instead of keeping the same approximate node size. I
> don't know if this is desirable or not.
>
> Also it seems to be a little slower. I am testing on a pretty fast machine,
> so if its a significant slow down for anyone I might have to reconsider how
> I do some things.
>
> Attached is the new function, as well as two tests functions for the new
> features. If anyone would like to test it and see if there are any bugs that
> would be great.


These pictures look great!

Jason

Ben Edwards

unread,
Aug 29, 2010, 3:28:11 PM8/29/10
to networkx...@googlegroups.com
Fixed a bug that drew other shaped markers incorrectly and am attaching a function that shows the different arrow styles, and how they point exactly to the outside of the node.

Ben

arrow_styles.png
arrow_styles.py
nx_pylab.py

Aric Hagberg

unread,
Aug 30, 2010, 10:13:45 AM8/30/10
to networkx...@googlegroups.com
On Sat, Aug 28, 2010 at 1:26 PM, Ben Edwards <BJEd...@gmail.com> wrote:

> New:
> Actual arrows drawn on DiGraphs
> Can control arrow style, and edge style, including the ability to have arced
> edges, check matplotlib's FancyArrowPatch
> Can use edge weights to scale thickness or edge color
> Can pass keyed dictionary for edge_color and node_color
> Cleaner code (somewhat)
> Different:
> Node size should be the same, as I do a conversion in the function. However,
> size is now absolute to the figure not just the axis (I am not sure how
> scatter does this) so in figures with subplots you have to scale up the
> nodes size. The factor is the number of subplot sections squared. So the
> examples four_grids.py should now have node sizes 4800, 0, 4000, 320. Also
> if you plot interactively, zooming the node or the entire figure actually
> zooms the node size instead of keeping the same approximate node size. I
> don't know if this is desirable or not.
> Also it seems to be a little slower. I am testing on a pretty fast machine,
> so if its a significant slow down for anyone  I might have to reconsider how
> I do some things.
> Attached is the new function, as well as two tests functions for the new
> features. If anyone would like to test it and see if there are any bugs that
> would be great.

Thanks for looking at this and updating the code. The arrows are great!

It definitely is slower to render. I'll review the code and see if
there is some way to speed
it up.

Aric

Ben Edwards

unread,
Aug 31, 2010, 12:15:21 PM8/31/10
to networkx-discuss
I am almost certainly sure it has to do with the fact that I am using
individual patches instead of collections. I'm doing this because the
FancyArrowPatch allows you to specify patches as endpoints and it will
automatically decide where the arrow should start and end.

I've tried creating a generic PatchCollection with the nodes, and then
adding that to the axes, but it seems the nodes don't render correctly
when I do this. Although I may have done something wrong.

Ben

On Aug 30, 8:13 am, Aric Hagberg <ahagb...@gmail.com> wrote:

franck kalala

unread,
Nov 4, 2010, 12:31:48 PM11/4/10
to networkx...@googlegroups.com
Hi
It seems that Networkx cannot read the pajek file attached.
Can some one help?
Cheers
Franco


I tryed this and it seems failed

>>> import networkx as nx
>>> G=nx.read_pajek("CrystalC.paj")

ValueError: need more than 1 value to unpack


CrystalC.paj

Aric Hagberg

unread,
Nov 4, 2010, 2:36:44 PM11/4/10
to networkx...@googlegroups.com

If you remove the beginning and ending of the file and only leave the
"vertices" and "edges" sections you should be able to read the file.

It looks like NetworkX doesn't support some of the Pajek data file
format sections.
We'd like to - but, as far as I know, there is no specification and
we don't have source to read to reverse engineer it.

Aric

Raf Guns

unread,
Nov 4, 2010, 4:38:57 PM11/4/10
to networkx...@googlegroups.com
Hi,

In general, NetworkX will only read/parse Pajek 'network' files
(*.net). The file format you're using (*.paj) is something else: it
can be used to put several networks together into one file, along with
related data structures like partitions and vectors. As far as I know,
those are not supported by NetworkX. (Also, it would complicate the
API, for what would be the return value of nx.read_pajek() in that
case?)

As Aric mentioned, the problem (one of the problems) is that there is
no real specification or source code, so implementing Pajek support is
rather difficult. Perhaps it might help if people could gather some
'real-world' Pajek files to test the NetworkX implementation against?

Best regards,

Raf

Drew Conway

unread,
Nov 4, 2010, 4:54:03 PM11/4/10
to networkx...@googlegroups.com
FWIW, the author of Pajek maintains a list of Pajek data files, but this lacks anything like a specification.


--
You received this message because you are subscribed to the Google Groups "networkx-discuss" group.
To post to this group, send email to networkx...@googlegroups.com.
To unsubscribe from this group, send email to networkx-discu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/networkx-discuss?hl=en.



___________________________________
Drew Conway
Ph.D. Student
Department of Politics, New York University
@drewconway

Aric Hagberg

unread,
Nov 4, 2010, 6:22:31 PM11/4/10
to networkx...@googlegroups.com
On Thu, Nov 4, 2010 at 2:38 PM, Raf Guns <raf...@gmail.com> wrote:
> Hi,
>
> On Thu, Nov 4, 2010 at 17:31, franck kalala <franck...@yahoo.fr> wrote:
>> Hi
>> It seems that Networkx cannot read the pajek file attached.
>> Can some one help?
>> Cheers
>> Franco
>>
>>
>> I tryed this and it seems failed
>>
>>>>> import networkx as nx
>>>>> G=nx.read_pajek("CrystalC.paj")
>>
>> ValueError: need more than 1 value to unpack
>
> In general, NetworkX will only read/parse Pajek 'network' files
> (*.net). The file format you're using (*.paj) is something else: it
> can be used to put several networks together into one file, along with
> related data structures like partitions and vectors. As far as I know,
> those are not supported by NetworkX. (Also, it would complicate the
> API, for what would be the return value of nx.read_pajek() in that
> case?)

We could easily make two functions - one to read Pajek .net and the
other to read Pajek .paj (which would return a list of graphs).

Aric

franck kalala

unread,
Nov 4, 2010, 6:49:42 PM11/4/10
to networkx...@googlegroups.com
Hi,

I have removed the beginning and end of the file and only keep "vertices" and
"edges" or "arcs" sections, see the attached file. But I still not able to read
it.

Cheers
Franco

----- Message d'origine ----
De : Aric Hagberg <ahag...@gmail.com>
À : networkx...@googlegroups.com
Envoyé le : Jeu 4 novembre 2010, 18h 36min 44s
Objet : Re: [networkx-discuss] read_pajek

Aric

--

CrystalC1.paj

Aric Hagberg

unread,
Nov 4, 2010, 7:19:49 PM11/4/10
to networkx...@googlegroups.com
On Thu, Nov 4, 2010 at 4:49 PM, franck kalala <franck...@yahoo.fr> wrote:
> Hi,
>
> I have removed  the beginning and end  of the file and only keep "vertices" and
> "edges" or "arcs" sections, see the attached file. But I still not able to read
> it.

Looks like the blank lines at the end are causing a problem so you'll
need to remove those too. (This we can fix easily in the code).

Aric

franck kalala

unread,
Nov 4, 2010, 7:48:25 PM11/4/10
to networkx...@googlegroups.com
The problem has been solved,
Thx Aric

----- Message d'origine ----
De : Aric Hagberg <ahag...@gmail.com>
À : networkx...@googlegroups.com

Envoyé le : Jeu 4 novembre 2010, 23h 19min 49s
Objet : Re: Re : [networkx-discuss] read_pajek

Aric

--

Richard Careaga

unread,
Nov 4, 2010, 8:34:05 PM11/4/10
to networkx...@googlegroups.com
This doesn't look terribly hard to parse, although I personally have not actually attempted it (in the interests of full disclosure).

Here's a portion of the Tina.paj file with my comments after the hash

*network DisCal # graph name attribute
*vertices   11 # start nodes, number nodes
% discussion, recall #comment or possible graph  attribute
  1 "minister 1" # nodes
  2 "p.minister"
  3 "minister 2"
  4 "minister 3"
  5 "minister 4"
  6 "minister 5"
  7 "minister 6"
  8 "minister 7"
  9 "adviser 1"
 10 "adviser 2"
 11 "adviser 3"
*matrix # start adjacency list, read using from_numpy_matrix
 0 1 1 0 0 1 0 0 0 0 0
 0 0 0 0 0 0 0 1 0 0 0
 1 1 0 1 0 1 1 1 0 0 0
 0 0 0 0 0 0 1 1 0 0 0
 0 1 0 1 0 1 1 1 0 0 0
 0 1 0 1 1 0 1 1 0 0 0
 0 0 0 1 0 0 0 1 1 0 1
 0 1 0 1 0 0 1 0 0 0 1
 0 0 0 1 0 0 1 1 0 0 1
 1 0 1 1 1 0 0 0 0 0 0
 0 0 0 0 0 1 0 1 1 0 0

What seems to require some effort is relating the nodes to the matrix.

Giovanni Marco Dall'Olio

unread,
Nov 5, 2010, 5:29:43 AM11/5/10
to networkx...@googlegroups.com

An alternative would be to write an iterator. For example:

python>>> from networkx import pajekIterator
python>>> mynetworksiterator = pajekIterator('myfile.paj')
python>>> mynetworkiterator.next()
python>>> for network in mynetworksiterator:
python>>> ... print network
python>>>

This has the advantage that, if the .paj files is very big and contains too many entries, it is still possible to read it without getting a memory error. It is the same approach used in BioPython to read fasta files, which can contain multiple entries.
Moreover, it is better suited for parallel programming.

 


Aric

--
You received this message because you are subscribed to the Google Groups "networkx-discuss" group.
To post to this group, send email to networkx...@googlegroups.com.
To unsubscribe from this group, send email to networkx-discu...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/networkx-discuss?hl=en.




--
Giovanni Dall'Olio, phd student
Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain)

My blog on bioinformatics: http://bioinfoblog.it

Reply all
Reply to author
Forward
0 new messages