Hello, > I think object oriented programming is the right tool to handle such > issues, and well, Python is object oriented!
You seem to address a problem different than mine. You want to split the graph class into something like LoopedGraph SimpleGraph LoopedMultiGraph MultiGraph That would leave us with no need for a Graph class, but you end your message by saying that Graph should "the subclassing job with a nice system of options, defaults and documentation." This thread, and my branch, are precisely about how such a subclassing (i.e. how to auto-detect the graph attributes) should be done when Graph is called. How would you do that ? My opinion is that Graph(list_of_edges) should always return a simple graph, unless explicitly mentionned otherwise. My ticket deprecates the current behaviour to this aim. This, to prevent users of graphs with multiple edges to create a simple graph by mistake, which could lead to wrong results. > I suggest that graph theoretists put their methods within SimpleGraph by > default, and if someone discover that the method remains valid in a more > general setting (perhaps after some tuning), then promote it to a more > general class ;) If graph theoretists only work within SimpleGraph class > (which is legitimate), the other classes will not progress as fast, but at > least the end-user will not be mislead and pitfalls will be avoided. Bear in mind that a user with a LoopedGraph in hand would probably see very very very few methods available, and as a result may never get to learn what he could do by casting his graph to a simple one. > It is still possible to have a Graph() constructor that does the > subclassing job with a nice system of options, defaults and documentation. And this thread is precisely about that. > I also think that well-identified classes will make the code more > penetrable to newcommers. 4 classes instead of one ?... More penetrable ?... > There is > already a BipartiteGraph class (which feels alone) This class is a disaster, I would love to remove it. Why ? Graphs are mutable, and BipartiteGraph instances too. Thus, add_edge can raise an exception, if by adding this edge the graph becomes non-bipartite. Worse: the class pre-computes a 2-coloring, and checks if adding an edge is allowed by the existing 2-coloring. Illustration: sage: g=BipartiteGraph(45) # 45 vertices, no edge sage: g.add_edge(0,1) ... RuntimeError: Edge vertices must lie in different partitions. As a result, many functions cannot even be defined on them... G.complement will only exist when your graph has very few vertices. Somebody even suggested once that BipartiteGraph.complement() should only complement the edges between the two components, so that g.complement() would not be the same graph as BipartiteGraph(g).complement() This is a disaster. If you want graphs to remember some properties you must make them immutable, or you have to check the property each time the graph is modified. Additionally (1) if you want Sage to do something with respect to graph classes, please help me by reviewing this: http://trac.sagemath.org/ticket/14396 Additionally (2) Thierry, I need help to review my ticket, the one this thread is about. I am stuck here. I do not mind discussing a complete rewrite of the graph classes, but I need somebody to come and review this patch, I am stuck otherwise. So please: a) If you are willing to review it you can make a mess of this thread, talk about whatever you like and I will join you gladly b) If you are not willing to review it, create another thread for your classes problem. Because I am stuck with this patch for as long as nobody comes review it. Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
