Where we are purely testing for a second order graph in order to
switch to a simpler output (otherwise second order graphs would
generate lots of confusing output on the command line).
Sorry, but I haven't actually read all of your stuff about what you were
going to achieve, but the above together with your initial intend
written on the first few lines of
http://www.euclideanspace.com/maths/standards/program/mycode/discrete/graph/design/multilevel/
rather tells me that you *don't* want to do second order graphs by
simply calling something like
DirectedGraph(DirectedGraph S)
At least I wouldn't design it that way. Much better IMHO would be to
construct
Directed2Graph(S: SetCategory): Directed2GraphExports(S) ==
DirectedGraph(DirectedGraph S) add
-- here come all the functions that you override.
Do you see the difference to your approach? I *hide* how "2-graphs"
(something like what you refer to by 2-category structures) are actually
implemented. Most important for me is, what *functionality* such
2-structures should export. Don't fear to introduce new domains and
categories. In my approach you can completely forget about code that
tests for second order graphs because if you have an element of
Directed2Graph, it *is* know to be a second order graph.
Does that sound reasonable?
Ralf
--
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.
