The unpac monorepo manager self-hosting as a monorepo using unpac
improving FAQ
+25
-16
+25
-16
FAQ
+25
-16
FAQ
···
7
7
I need several kind of labels on the edges
8
8
-----
9
9
A: Use one of the functor implementation provided in Persistent or Imperative.
10
-
If for instance you want mutable directed graphs with colored vertices,
10
+
If for instance you want mutable directed graphs with colored vertices,
11
11
you may do
12
12
13
13
type color = Red | Green | Blue | Yellow
···
16
16
(to be able to change the color you would use `type t = color ref' instead)
17
17
==========
18
18
==========
19
-
Q: How to choose between concrete and abstract vertices for my graph
19
+
Q: How to choose between concrete and abstract vertices for my graph
20
20
implementation?
21
21
-----
22
22
A: If you fall into one of the following cases, use abstract vertices:
···
32
32
33
33
But abstract graphs use integer tags to identify vertices;
34
34
this tag is made from the global reference [Blocks.cpt_vertex].
35
-
If you need to create new vertices after the unserialisation of an abstract
36
-
graph, you have to
37
-
- serialize [!Blocks.cpt_vertex]
38
-
- call function [Blocks.after_unserialization] after your unserialisation
39
-
process.
35
+
There are two related issues.
36
+
37
+
1) If there are abstract vertices in RAM while unmarshalling some others,
38
+
you have to be sure that RAM vertices do not share tags with unmarshalled
39
+
ones (except if you really want that).
40
+
41
+
2) If you need to create new vertices after unserialising an abstract graph,
42
+
you have to:
43
+
- serialize [!Blocks.cpt_vertex];
44
+
- call function [Blocks.after_unserialization] after your unserialisation
45
+
process.
46
+
47
+
There is no issue with concrete graph: it may be easier to use them if
48
+
unmarshalling is required.
40
49
==========
41
50
==========
42
51
Q: I need Foobar-Tarjan algorithm and it is not provided
···
44
53
A: Please contribute by sending us the code :-) See next question.
45
54
==========
46
55
==========
47
-
Q: How can I contribute to this library?
56
+
Q: How can I contribute to this library?
48
57
-----
49
-
A: You can contribute either with a graph data structure or with an algorithm
50
-
over graphs. For the former, please follow the signatures given in module
58
+
A: You can contribute either with a graph data structure or with an algorithm
59
+
over graphs. For the former, please follow the signatures given in module
51
60
Sig. For the latter, write your algorithm as a functor, following examples
52
61
in modules Path, Flow, Components, etc.
53
62
==========
···
55
64
Q: Your implementation of algorithm AAA could be greatly improved provided
56
65
you add this and this into the graph data structure
57
66
-----
58
-
A: Of course yes. But the idea behind ocamlgraph is to be as generic as
67
+
A: Of course yes. But the idea behind ocamlgraph is to be as generic as
59
68
possible (any algorithm should be useable on any implementation).
60
69
61
70
When the graph data structure provides additional capabilities
62
-
(such as marking, etc.) it is possible to provide a more efficient
63
-
implementation into some specialized functor. See module Traverse for
71
+
(such as marking, etc.) it is possible to provide a more efficient
72
+
implementation into some specialized functor. See module Traverse for
64
73
instance (where DFS and cycle detection are optimized for imperative
65
74
graphs equipped with marks)
66
75
==========
···
68
77
Q: I have a graph implementation with polymorphic types for vertices or edges
69
78
and thus I can't apply the algorithms functors
70
79
-----
71
-
A: Here we bump into Ocaml's type system limitations: the number of type
72
-
parameters must be know when the functor is written and the simplest
80
+
A: Here we bump into Ocaml's type system limitations: the number of type
81
+
parameters must be know when the functor is written and the simplest
73
82
choice for us was to assume no type parameter at all. (This is exactly the
74
-
same for functors Set.Make or Map.Make from Ocaml standard library.)
83
+
same for functors Set.Make or Map.Make from Ocaml standard library.)
75
84
As a (bad) workaround, you can copy the functor body and substitute your
76
85
own functions for the functor arguments.
77
86
==========