$ python3.1 -m igraph.test.__init__
................................................................
................................................................
................................................................
..............................
----------------------------------------------------------------
Ran 222 tests in 1.802s

OK

Therefore, I'm happy to announce that python-igraph will officially support Python 3 starting from the next major release; that is, 0.6. If you can't wait till the next release and would like to take it for a test drive, you can grab the nightly builds from Google Code and compile them for yourself.

$(__git_ps1 "(%s)")

Make sure that you use single quotes when you set the bash prompt (e.g., export PS1='...' instead of export PS1="...") to ensure that the command is executed every time the prompt is displayed.

You may also use specific environment variables to tweak the behaviour of __git_ps1:

export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export GIT_PS1_SHOWSTASHSTATE=true

Requirements

If you want to try this add-on, you will need the following:

• Python 2.5 or later. To tell the truth, I've only tested the module in Python 2.6, but it should work in Python 2.5 as well - if not, let me know! Python 3 is not supported yet as igraph itself does not support Python 3.

• igraph 0.5.3 or later and its Python bindings.

• A working mencoder executable somewhere in your path. If you have it but you don't want to add it to your path, that's fine, just remember to pass the full path of the executable to the MEncoderVideoEncoder constructor in the examples.

Of course you will also need the add-on itself.

Where to get it from

The add-on is currently hosted on GitHub; click here to download it. Place the file somewhere on your Python path so Python can find it, then type from video import MEncoderVideoEncoder.

The basic API

The essence of the add-on is an abstract class called VideoEncoder, and its derived subclasses. Well, that's an overstatement, since currently the only subclass of VideoEncoder is MEncoderVideoEncoder, which teaches igraph how to handle MEncoder in order to encode a series of images into an AVI file. So, the first step is always to construct an instance of an appropriate VideoEncoder subclass; e.g.:

encoder = MEncoderVideoEncoder()

At construction time, you may also specify the bounding box (i.e. the width and height) of the video and the number of frames per second (FPS). The default FPS value is 25. This is how to override the bounding box and the FPS:

encoder = MEncoderVideoEncoder(bbox=(400, 300), fps=12)

You can also override the bounding box and the FPS later by assigning new values to the corresponding instance attributes:

encoder.bbox = (500, 400)
encoder.fps = 24

Besides these attributes, you will only need the add() and save() methods of the encoder instance. add() adds the next frame to the animation, while save() saves the whole animation to an AVI file. add() accepts names of image files, igraph's Plot objects, or any plottable igraph object (such as Graph); in the latter case, a corresponding Plot object will be created automatically and added to the video sequence. For example:

encoder.add("my_title_page.png")
 
p = igraph.Plot(bbox=(500, 400))
p.add(graph, vertex_color="green")
encoder.add(p)
 
encoder.add(graph, layout="kamada_kawai")

The supported image formats depend solely on the video encoding backend; in case of MEncoder, you can safely use either PNG or JPG files. Finally, when you have added all the frames in the right order, you have to call save() to start encoding the video:

encoder.save("my_video.avi")

There is also an alternative syntax using Python's with keyword:

encoder = MEncoderVideoEncoder(bbox=(400, 300), fps=12)
with encoder.encode_to("my_video.avi"):
    # Here you can add your frames by calling encoder.add()

The video encoding will then start automatically as soon as Python leaves the indented with block -- no need to call save() at all.

Behind the scenes

MEncoderVideoEncoder manages a temporary directory in the background. Frames you have added to the video stream are stored in this temporary directory (unless they were already saved as image files on the hard drive). This means that when you add() a Plot instance or a plottable igraph object, it is rendered immediately to a file in the temporary directory. You can keep on modifying the object you have plotted without affecting the frame. The temporary directory is removed either when the video encoder object is garbage collected or deleted with the del operator, or when the save() function returns successfully. This means that you do not have to worry about the temporary directory (in fact, you do not even have to know that it exists), everything will be cleaned up properly, even if an exception happens while you are constructing the frames.

You may have also noticed that I have not mentioned how to specify the codec used during encoding. The default codec is msmpeg4v2, as it seems to be the only codec that is installed on a vanilla Windows XP. If you need a better codec (well, it's not too hard to be better than msmpeg4v2 anyway), you can modify the lavcopts attribute of the MEncoderVideoEncoder instance -- this tweaks the value of the -lavcopts command line switch of mencoder. Please refer to the relevant chapter of the MEncoder documentation for more information. The lavcopts instance variable accepts both strings and dictionaries; e.g., the following two calls are equivalent:

encoder.lavcopts = "vcodec=mpeg4:mbd=2:vbitrate=1600:trell:keyint=50"
encoder.lavcopts = {
    "vcodec": "mpeg4",
    "mbd": 2,
    "vbitrate": 1600,
    "trell": True,
    "keyint": 50
}

Setting lavcopts to None resets it to the default value, which is vcodec=msmpeg4v2.

MEncoderVideoEncoder also has an instance variable named verbose. If verbose is True, the output of MEncoder will be piped back to the standard output of the invoking Python process, so you can directly see the progress messages from MEncoder. IF verbose is False, only error messages will be printed. The encoder is in quiet mode by default.

Example #1: Layout visualisation

This section presents a short code snippet that demonstrates how the GraphOpt layout algorithm works in igraph. The GraphOpt algorithm uses basic principles of physics to determine an optimal graph layout iteratively. Each node in the graph is given a mass and an electric charge, and each edge represents a spring. The layout is then calculated by simulating the actual physical system for a given number of steps.

In our example, we will visualise the GraphOpt algorithm by running it one step at a time and then adding the current layout to the video stream. We will make use of the fact that passing a keyword argument seed=... to the GraphOpt layout function will specify the initial layout the algorithm is started from. We will also calculate a clustering of the graph using the spinglass clustering algorithm and show how the nodes in the clusters are pulled close to each other by the layout algorithm. For the latter part, we will make use of a recent addition in igraph 0.6 which enables one to plot a VertexClustering object directly. The code is as follows (assuming that you have imported Graph from the igraph module and MEncoderVideoEncoder from the add-on):

# Generate graph and find the communities
graph = Graph.GRG(100, 0.2)
clusters = graph.community_spinglass()
 
# Specify initial layout
layout = None
 
# Set up the video encoder
encoder = MEncoderVideoEncoder(bbox=(600, 600), fps=30)
encoder.lavcopts = "vcodec=mpeg4:mbd=2:vbitrate=1600:trell:keyint=30"
 
# Generate frames in the animation one by one
with encoder.encode_to("demo_layout.avi"):
    for i in xrange(500):
        # Run one step of the layout algorithm
        layout = graph.layout("graphopt", niter=1, seed=layout)
        # Add the clustering to the encoder
        encoder.add(clusters, layout=layout, mark_groups=True, margin=20)

And this is how the result looks like:

Example #2: Epidemic spreading on networks

This example illustrates a simple epidemic spreading model called the SIR model on a geometric random graph. In the SIR model, each node can be in one of three states: S is susceptible (i.e. not infected, but prone to infections), I is infected and R is recovered (i.e. it was infected at some point, but it will not be infected again). Nodes start in the S state and move to the I state if they get infected. Once infected, a node will try to infect its neighbors in each time step with a spreading probability β. Infected nodes may recover from the infection in every time step with probability γ; after recovery, such nodes move to the R state and stay there forever.

When implementing the SIR model in Python using igraph, we attach an attribute named state to the vertices, denoting which state the vertex is in. We will also need a dictionary that maps vertex states to colors in the visualisation (red = infected, green = recovered, white = susceptible). The whole setup procedure is then as follows:

from igraph import Graph, Layout
from random import sample, random
 
# Specify the simulation parameters
initial_outbreak_size = 3
beta = 0.05
gamma = 0.1
 
# Set up the mapping from vertex states to colors
colormap=dict(S="white", I="red", R="green")
 
# Generate the graph and the layout
graph, xs, ys = Graph.GRG(100, 0.2, return_coordinates=True)
layout = Layout(zip(xs, ys))
 
# Set up the initial state of the individuals
graph.vs["state"] = ["S"] * graph.vcount()
for vertex in sample(graph.vs, initial_outbreak_size):
    graph.vs["state"] = "I"

The above code generates a geometric random graph with 100 vertices, lays them out on the 2D plane according to the original coordinates used in the generation process, then puts all the individuals into the susceptible (S) state save a few who will be infected already (I). Now we can move on to setting up the encoder and rendering the animation:

encoder = MEncoderVideoEncoder(bbox=(600, 600), fps=5)
while True:
    # Create a plot of the current state and add it to the encoder
    colors = [colormap[state] for state in graph.vs["state"]]
    encoder.add(graph, layout=layout, vertex_color=colors,
                vertex_label=graph.vs["state"], margin=20)
 
    # First, the infected individuals try to infect their neighbors        
    infected = graph.vs.select(state="I")
    for vertex in infected:
        for idx in graph.neighbors(vertex.index):
            if graph.vs[idx]["state"] == "S" and random() < beta:
                graph.vs[idx]["state"] = "I"
 
    # Second, the infected individuals try to recover
    for vertex in infected:
        if random() < gamma:
            vertex["state"] = "R"
 
    # Okay, are there any infected people left?
    if not infected:
        break
encoder.save("demo_epidemic.avi")

Note that it takes a relatively short time until the infection spreads to almost the whole network, and how it takes much longer for the last infected nodes to recover, even though the spreading probability is smaller than the recovery probability. This is because a node almost always has multiple chances to infect in a single time step (since it tries all its susceptible neighbors), while it has only one chance to recover. See the full result here:

Concluding remarks

The whole video encoder API is unstable yet. It might eventually get included in the Python interface of igraph, but I'd love to hear your comments first. Can it be made any simpler than this? Shall I add support for FFMpeg or PyMedia? Are there some features missing? Would you like to see it as part of the Python interface, or shall I leave it separate? Feel free to comment or send me an email.

igraph uses Cairo as a plotting backend. If you dive into the plotting internals of igraph, you will see that every plottable object has a method called __plot__, which is called when the object has to be plotted on a Cairo surface. (The plotting code has undergone major refactoring in the last few weeks, therefore things are likely to change in igraph 0.6, but the __plot__ method will be kept for sake of compatibility anyway). For instance, Graph.__plot__ is called with a Cairo context ctx, a bounding box bbox in which the graph has to be drawn, and a palette that is used occasionally to resolve numeric color indices to RGB triplets. This means that I would only have to extract the Cairo context that Matplotlib uses to draw the figures and pass it on to Graph.__plot__ somehow.

Matplotlib, on the other hand, can work not only on Cairo contexts but all sorts of different backends (e.g., it can render plots on a GTK surface using Agg, or on the surface of a Qt window and so on). The difference between backends is abstracted away by the concept of renderers, which offer a common interface to high-level Matplotlib entities (artists in Matplotlib lingo). When a curve is plotted in matplotlib, the curve object itself does not talk to the backend, it talks to the renderer instead. If we want to hijack the plotting process of Matplotlib, we have to implement our own artist that draws igraph graphs and inject it into a Matplotlib figure.

Matplotlib artists are abstract classes that require subclasses to implement a method called draw, which expects a renderer and takes care of drawing the artist itself using the renderer. When we put all this together, it turns out that it is remarkably simple to implement an artist for igraph graphs:

from matplotlib.artist import Artist
from igraph import BoundingBox, Graph, palettes
 
class GraphArtist(Artist):
    def __init__(self, graph, bbox, palette=None, *args, **kwds):
        """Constructs a graph artist that draws the given graph
        within the given bounding box."""
        Artist.__init__(self)
        self.graph = graph
        self.palette = palette or palettes["gray"]
        self.bbox = BoundingBox(bbox)
        self.args, self.kwds = args, kwds
 
    def draw(self, renderer):
        from matplotlib.backends.backend_cairo import RendererCairo
        if not isinstance(renderer, RendererCairo):
            raise TypeError("backend not supported")
        ctx = renderer.gc.ctx if hasattr(renderer, "gc") else renderer.ctx
        self.graph.__plot__(ctx, self.bbox, self.palette, *self.args, **self.kwds)

The usage of GraphArtist is pretty simple. First, we have to make sure that Matplotlib uses the Cairo plotting backend (as this is the only one supported by GraphArtist):

import matplotlib
matplotlib.use("cairo.pdf")

After that, we can move on to creating a figure with a 2D plot:

import matplotlib.pyplot as pyplot
figure = pyplot.figure()
axes = figure.add_subplot(111)
xs = range(200)
ys = [math.sin(x/10.) for x in xs]
axes.plot(xs, ys)

Now, we have to construct a GraphArtist for our graph to be plotted (say, graph) and add it to the figure. The trick here is that we have to add the artist to the axes and not the figure, since the axes of a Matplotlib figure are always drawn on top of any other artist added to the figure, and we want to ensure that our graph appears on top of the plot itself:

graph_artist = GraphArtist(graph, (10, 10, 150, 150), layout="kk")
graph_artist.set_zorder(float('inf'))
axes.artists.append(graph_artist)
fig.savefig("test.pdf")

The first line constructs the artist itself, using a bounding box spanning from (10, 10) to (150, 150). The remaining positional and keyword arguments (such as layout="kk") will be passed on intact to Graph.__plot__. The second line sets the Z-order of the artist to infinity to ensure that it is drawn on top of any curves that were added to the axes before. Finally, the artist is appended to the list of artists managed by axes and the figure is saved to the given PDF file.

Click here to download the source code.

1. Pick the median element A of the smaller set.
2. Search for the insertion point B of this element in the larger set.
3. If A equals B, add A to the result set.
4. Repeat the previous three steps for non-empty subsets to the left and right of A and B.

A big kudos goes to Erik Frey for drawing my attention to the above procedure. According to his measurements, the algorithm works even better if one uses interpolation search instead of binary search, but it did not yield performance improvements compared to the binary search case in igraph, so I decided to go with binary search only. Some quick measurements on geometric random graphs with an increasing number of vertices (while keeping the density constant) show that indeed the improvements in the set intersection algorithm speeded up the maximal clique search significantly (red line shows the old Bron-Kerbosch implementation with linear set intersection, blue line shows the new one):

This will be included in the next major release of igraph.

The first is that Python was upgraded to a 64-bit version of the 2.6.1 release. This means that all the Python extensions I used that have parts written in C have to be recompiled from scratch for the 64-bit version. Not a big deal - as long as you don't use any extensions that depend on 32-bit third party libraries. One example is Syck, a YAML parser written in C. I used to install Syck from Fink, but Fink only supplies a 32-bit version, not a 64-bit one, so for the time being I am stuck with a 32-bit version... which means that I have to run Python in 32-bit mode. Luckily, there are at least two ways to switch back to the 32-bit implementation. One is to change the corresponding setting permanently:

$ defaults write com.apple.versioner.python Prefer-32-Bit -bool yes

The other possibility is an environment variable called VERSIONER_PYTHON_PREFER_32_BIT which should be set to either yes or no.

Another catch lies in gcc which also produces 64-bit code by default. This means that it won't be able to link to a static or dynamic library compiled earlier with Leopard in 32-bit mode; either the library has to be recompiled or gcc should be instructed to produce 32-bit code:

$ gcc -arch i386 ...the rest is the same

1. Launch Safari and checks its "About" box in the "Safari" menu. Look for the bundle number in parentheses after the version number (mine reads 5525.18 now).
2. Close Safari.
3. Open /Library/Application Support/SIMBL/Plugins/PithHelmet.bundle/Contents/Info.plist in the Property List Editor and search for /Root/SIMBLTargetApplications/0/MaxBundleVersion. Set its value to the bundle number of your Safari (the part before the dot, so it is 5525 in my case).
4. Relauch Safari and everything should work as expected.

Note that this is a really ugly hack, and it works only as long as there are no incompatible changes between different versions of Safari that would prevent PithHelmet from operating properly. It looks like it works with Safari 3.1, but there is no warranty that it will work with later versions as well.

Mellesleg van még egy alternatíva, a Hungarian Pro kiosztás. Ezzel annyi a probléma, hogy a Caps Lock gombot "elhasználja" az Unicode és a Central European karakterkódolás közötti váltásra. Mivel én szinte kizárólag Unicode-ban dolgozom, viszont a Caps Lock-ra szükségem van, ez a megoldás jobbnak látszott (arról nem is beszélve, hogy a PRG kiosztást Gaba eleve programozóknak szánta).

Telepítési instrukciók

1. Töltsd le a fenti .dmg fájlt és nyisd meg Finder-ben
2. A .dmg-ben lévő két fájlt másold be a /Library/Keyboard Layouts könyvtárba. Ha csak a saját felhasználód számára szeretnéd elérhetővé tenni, akkor elég, ha a home-odon belül lévő Library/Keyboard Layouts könyvtárba másolod.
3. Jelentkezz ki és jelentkezz be újra! Ez a lépés fontos, enélkül a lépés nélkül nálam a billentyűzetkiosztás kiválasztásakor semmilyen billentyűleütésre nem reagált az OS X, viszont gyönyörűen elkezdett strandlabdázni az az alkalmazás, amelyben gépeltem.
4. A System Preferences-ben az International / Input Menu alatt keresd meg a kiosztást és válaszd ki.

Hibajelzéseket és hasonlóakat kommentekben szívesen fogadok.

Köszönetnyilvánítás

Nagy köszönet Gabának, amiért közzétette a Hungarian-PRG kiosztást, enélkül valószínűleg soha nem jutott volna eszembe, hogy itt keressem a hibát.