> I forgot to mention one of the main advantages of (logically) immutable > objects (better late than never): You cannot cache anything if you allow an > object representing one mathematical entity to be modified into something > completely different. Now perhaps you only care about having the worlds > fastest graph_frobnicate() implementation, but you want others to use graphs > to build their own algorithms on top then it quickly gets painful that every > call to automorphism_group() always computes the automorphism group from > scratch.
I agree that you may want to compute automorphisms groups quickly, but it quickly gets painful that every edge addition requires a whole copy of the graph's structure :-p Dear friend, what we need is an immutable graph backend.You should not have to wait for so long to test adjacencies in graphs because *I* need to modify mine. It's much faster to do when you use a data structure that does not have to be reallocated every ten seconds [1]. On the other hand, if you sometimes need to run NP-complete algorithms it is not very hard to make a copy of your graph before running them, it is very very very cheap compared to the algorithm itself. And I still think that in such a situation it would be a very bad choice to inherit all methods from the current Graph classes. You compute diameters ? Radii ? Distance distribution ? Well, perhaps you will agree that you can save quite some time if you know that your graph is vertex-transitive ! Even subgraph search should be improved ! The default plot layout would be soooo different too !! The advantages : you can store whatever you want in the graphs, you can call the usual Graph stuff on a copy of you graph at the slightest occasion, all the basic operations are *DEAD FASTER*, and you would not even have to support labels (my personal dream) as GAP does not support them anyway :-p I would use them much myself by the way, to have graphs as dictionary keys and to speedup a few things without going C-deep. Of course, as Dima said several times -- and as I noticed myself muuuch later and through his many hints -- is that you probably do not always need to store the graph structure itself (i.e. the adjacencies). Let's just have two independent classes that apparently do the same stuff, but in very different ways ! We would have methods to convert one into the other, and we could optimize stuff specifically for each problem instead of sharing each other's problems on ill-adapted data structures ! :-p Nathann [1] http://www.sagemath.org/doc/reference/sage/graphs/base/static_sparse_graph.html -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
