>
> I have added a new function 'toCayleyGraph' to MultifunctionGraph. If
> it is too late to include it in the next release I will merge it in
> afterwards. I just thought I would mention it in case there is still
> time.
>
> https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet
>
Martin, I looked closed at the whole graph package and I see
several (mostly small) problems:
1) Unicode characters in comments, this causes compilation
failures in some locales (notably C locale).
2) Your nodes are from some set, but on input you only allow
specifying arrows by indices (numbers). IMHO it is much
more elegant to specify arrows giving from and to nodes.
That is have:
addArrow! : (%, String, S, S) -> %
Version with numbers should be only used for efficiency or
in code when numbers are available. It is easy to implement
such funtion by adding:
getVertexIndex(s : %, o : S) : NNI ==
for i in 1.. for v in getVertices(s) repeat
if v.value = o then return i
error "getVertexIndex : vertex not found"
addArrow!(s : %, name : String, o1 : S, o2 : S) : % ==
addArrow!(s, name, getVertexIndex(s, o1), getVertexIndex(s, o2))
I think that getVertexIndex should be exported too.
3) In 'incidenceMatrix' you only take into account starting point
of an arrow. But standard definition also includes endpoint
(you are supposed to be able to reconstruct graph from its
incidence matrix, standard definition allows it, your code
not). Also, for directed graphs entry corresponding to
start point is -1, while for directed graph it is 1.
4) AFAICS FunctionGraph domain and MultifunctionGraph are mostly
redundant:
- Logically they are just graphs that satisfy appropriate
predicate. Given that most operations on graphs do not
preserve this predicate having separate types gives little
gain and IMHO it is better to just provide predicates
'functionGraph? : % -> Boolean' and
'multifunctionGraph? : (S, NNI) -> Boolean'.
- they provide their own representation, but case of
FunctionGraph seem too special to optimize for, and
in case of MultifunctionGraph the representation is
capable of representing arbitrary graphs (in fact,
I feel that it is better representation than the
one used in DirectedGraph). So again I see no
reason for special representation.
- few operations that are special to both domains could
be moved to DirectedGraph
- my impression is that at least MultifunctionGraph allows
you to create graph which does not satisfy its predicate
5) Documentation for your functions shows poorly in HyperDoc.
The normal style is to write something like:
++ addArrow!(s, nm, o1, o2) adds an arrow to the graph s,where:
++ nm is the name of the arrow
++ o1 is the start object
++ o2 is the end object
You wrote:
addArrow!:(s:%,name:String,n1:NNI,n2:NNI) -> %
++ adds an arrow to this graph,where:
++ s is the graph where the arrow is to be added
++ nm is the name of the arrow
++ n1 is the index of the start object
++ n2 is the index of the end object
Unfortunatly, Spad compiler simply ignores names given in the
first line, so HypeDoc shows:
addArrow!(x, y, i, j)
++ adds an arrow to this graph,where:
++ s is the graph where the arrow is to be added
++ nm is the name of the arrow
++ n1 is the index of the start object
++ n2 is the index of the end object
and the user has no idea what are correct arguments to the
function.
6) Parts of documentation are not up to date. For example
in WeightedGraph:
++ At the moment weights are restricted to NNI but I may change that to
++ real (DoubleFloat) numbers.
but AFAICS WeightedGraph already allows weights from
OrderedAbelianMonoid.
I think I could quickly correct most of the above problems,
but I am not sure how you feel about this (in particlar about
getting rid of FunctionGraph and MultifunctionGraph).
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
