On Saturday 31 Mar 2012 17:55:37 Ralf Hemmecke wrote: > 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.
One type of functionality, is something like flatten: (n:DirectedGraph(%)) -> % which is here: https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet#L1173 Another type of functionality is just to be able to draw 2-graphs in a useful way that allows these structures to be visualised. https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet#L2036 Another type of functionality is that I would like to reformulate functions like 'coAdjoint' here: https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet#L2973 and put this into a 2-graph context. Finally I would like to be able to translate these structures to and from other structures. For example, from graphs which have arrows between arrows. > 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? Yes, my first instinct was to have a separate domain for 2-graphs but then I tried to do it this way because, 1) As you say, I am concerned about introducing new domains, at the moment there are 5 flavours of 1-graphs so there would be 25 flavours of 2-graphs, such as, a DirectedGraph of UndirectedGraphs a WeightedGraph of MultifunctionGraphs and so on.... 2) If it ever becomes possible to have a monad category in Fricas then it would be good to implement it for graphs. If this were done then it seems to me that we would need to have signatures more like: flatten:(n:DirectedGraph(DirectedGraph(S))) -> DirectedGraph(S) rather than: flatten:(n:Directed2Graph(S)) -> DirectedGraph(S) I think you are probably right, given the problems with the way I tried to do it, it would be better to have new domains for 2-graphs, I just want to try to understand the pros and cons. Martin -- 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.
