On 02/20/2014 09:03 AM, Stefan Klingelschmitt wrote:

Hey,

I'm struggeling with the grap_union() function. It seems like the properties are only correctly passed to the union graph, if include=True. Is this how it supposed to work? Here a minimal example:

import graph_tool.all as gt import graph_tool.topology as gt_topo from gi.repository import Gtk, Gdk, GdkPixbuf, GObject

G = gt.Graph(directed=False) G_sub = gt.Graph(directed=False)

v1 = G.add_vertex() v2 = G.add_vertex() v3 = G.add_vertex()

v4 = G_sub.add_vertex() v5 = G_sub.add_vertex()

e1 = G.add_edge(v2, v1) e2 = G.add_edge(v2, v3)

e3 = G_sub.add_edge(v5, v4)

G.vertex_properties['type'] = G.new_vertex_property("string")

G_sub.vertex_properties['type'] = G_sub.new_vertex_property("string")

G.vertex_properties['type'][v1] = 'Car' G.vertex_properties['type'][v2] = 'Crossing' G.vertex_properties['type'][v3] = 'Car'

G_sub.vertex_properties['type'][v4] = 'Pedestrian' G_sub.vertex_properties['type'][v5] = 'Sidewalk'

#ToDo: Function bug, why is include=True needed? G_union, prop = gt.graph_union(G, G_sub, props=[(G.vertex_properties['type'], \ G_sub.vertex_properties['type'])], include=True)

pos = gt.sfdp_layout(G) gt.graph_draw(G_union, pos, vertex_text=G_union.vertex_properties['type'])

No, include = True is not needed. The collected properties are always returned via the "prop" variable, which you are ignoring. You should use prop[0] as the parameter to vertex_text in graph_draw(), to see the correct behavior. The union graph never contains internal properties (unless include == True), as you seem to be expecting.

Another point that I find a bit not so intuitive is that you have to specify every single property of the two graphs you would like to have in the new graph, wouldn't it be much more intuitive to copy all the properties into the new graph unless not told otherwise?

The graph_union() functions ignores the existence of internal properties for simplicity, and only considers explicitly given ones. The reason for this is that that may be cases where internal properties have the same name but have different and nonconvertible types. In this case, which could occur rather often, the union would fail.

However, with the current function, I agree that it is actually somewhat cumbersome to perform an union of graphs with many internal properties, which may be desired. I think it would make sense to include this as an option... I'll try to get around to improving this in the next release. (You could open a ticket in the website, to make sure I don't forget).

Best, Tiago