Home | Trees | Indices | Help |
|
---|
|
Directed multi-graph with constrained labeling. Provides facilities to define labeling functions on vertices and edges, with given co-domains, so that labels are type-checked, not arbitrary. Each state (or edge) is annotated with labels. Before removing a value from a label type, first make sure no state (or edge) is labeled with it. Multiple edges with the same C{attr_dict} are not possible. So the difference from C{networkx.MultiDiGraph} is that the C{dict} of edges between u,v is a bijection. Between two nodes either: - a single unlabeled edge exists (no labeling constraints), or - labeled edges exist but mixing labeled with unlabeled edges for the same edge is not allowed, to simplify and avoid confusion. Label types by example ====================== Use a C{dict} for each label type you want to define, like this: >>> types = [ {'name': 'drink', 'values': {'tea', 'coffee'}, 'setter': True, 'default': 'tea'}] This will create a label type named C{'drink'} that can take the values C{'tea'} and C{'coffee'}. Assuming this label type applies to nodes, you can now label a new node as: >>> g = LabeledDiGraph(types) >>> g.add_node(1, drink='coffee') If you omit the label when adding a new node, it gets the default value: >>> g.add_node(2) >>> g.node[2] {'drink': 'tea'} The main difference with vanilla C{networkx} is that the dict above includes type checking: >>> type(g.node[2]) tulip.transys.mathset.TypedDict The C{'setter'} key with value C{True} creates also a field C{g.drink}. Be careful to avoid name conflicts with existing networkx C{MultiDiGraph} attributes. This allows us to add more values after creating the graph: >>> g.drink {'coffee', 'tea'} >>> g.drink.add('water') {'coffee', 'tea', 'water'} Finally, the graph will prevent us from accidentally using an untyped label name, by raising an C{AttributeError}: >>> g.add_node(3, day='Jan') AttributeError: ... To add untyped labels, do so explicitly: >>> g.add_node(3, day='Jan', check=False) >>> g.node[3] {'day': 'Jan', 'drink': 'tea'} Details on label types ====================== Each label type is defined by a C{dict} that must have the keys C{'name'} and C{'values'}: - C{'name'}: with C{str} value - C{'values' : B} implements C{__contains__} used to check label validity. If you want the codomain C{B} to be extensible even after initialization, it must implement method C{add}. and optionally the keys: - C{'setter': C} with 3 possibilities: - if absent, then no C{setter} attribute is created - otherwise an attribute C{self.A} is created, pointing at: - the given co-domain C{B} if C{C is True} - C{C}, otherwise. - C{'default': d} is a value in C{B} to be returned for node and edge labels not yet explicitly specified by the user. @param node_label_types: applies to nodes, as described above. @type node_label_types: C{list} of C{dict} @param edge_label_types: applies to edges, as described above. @type node_label_types: C{list} of C{dict} @param deterministic: if True, then edge-label-deterministic Deprecated dot export ===================== BEWARE: the dot interface will be separated from the class itself. Some basic style definitions as below may remain, but masking selected labels and other features will be accessible only via functions. For dot export subclasses must define: - _state_label_def - _state_dot_label_format - _transition_label_def - _transition_dot_label_format - _transition_dot_mask Note: this interface will be improved in the future. Credits ======= Some code in overridden methods of C{networkx.MultiDiGraph} is adapted from C{networkx}, which is distributed under a BSD license.
Nested Classes | |
Inherited from Inherited from |
Instance Methods | |||
|
|||
bool |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
bool |
|
||
|
|||
Inherited from Inherited from Inherited from Inherited from Inherited from |
Properties | |
Inherited from Inherited from |
Method Details |
Initialize a graph with edges, name, graph attributes. Parameters ---------- data : input graph Data to initialize graph. If data=None (default) an empty graph is created. The data can be an edge list, or any NetworkX graph object. If the corresponding optional Python packages are installed the data can also be a NumPy matrix or 2d ndarray, a SciPy sparse matrix, or a PyGraphviz graph. name : string, optional (default='') An optional name for the graph. attr : keyword arguments, optional (default= no attributes) Attributes to add to graph as key=value pairs. See Also -------- convert Examples -------- >>> G = nx.Graph() # or DiGraph, MultiGraph, MultiDiGraph, etc >>> G = nx.Graph(name='my graph') >>> e = [(1,2),(2,3),(3,4)] # list of edges >>> G = nx.Graph(e) Arbitrary graph attribute pairs (key=value) may be assigned >>> G=nx.Graph(e, day="Friday") >>> G.graph {'day': 'Friday'}
|
Check if labels are consistent with their type definitions. Use case: removing values from a label type can invalidate existing labels that use them.
|
Use a TypedDict as attribute dict. Overrides Log warning if node already exists. All other functionality remains the same.
|
Create or label multiple nodes. Overrides
|
Use a TypedDict as attribute dict. Overrides
Each label defines a different labeled edge. So to "change" the label, either:
Notes
|
Add multiple labeled edges. Overrides Only difference is that only 2 and 3-tuple edges allowed. Keys cannot be specified, because a bijection is maintained.
|
Remove single labeled edge.
|
Remove labeled edges. Example>>> g = LabeledDiGraph() >>> g.add_edge(1, 2, day='Mon') >>> g.add_edge(1, 2, day='Tue') >>> edges = [(1, 2, {'day':'Mon'}), (1, 2, {'day':'Tue'})] >>> g.remove_edges_from(edges)
|
Return False if all nodes have outgoing edges. Edge labels are not taken into account. |
Return dot string. Requires pydot. |
Save image to file. Recommended file formats:
Any other format supported by Experimental:
Requires
and for tikz:
See Alsoplot,
|
Plot image using dot. No file I/O involved. Requires GraphViz dot and either Matplotlib or IPython. NetworkX does not yet support plotting multiple edges between 2 nodes. This method fixes that issue, so users don't need to look at files in a separate viewer during development. See AlsoDependsdot and either of IPython or Matplotlib |
Home | Trees | Indices | Help |
|
---|
Generated by Epydoc 3.0.1 on Sat Nov 19 00:11:17 2016 | http://epydoc.sourceforge.net |