> As a matroid theorist I care about creating millions and millions of small >>> graphs (10 vertices is already a LOT). I don't modify them once they're >>> ready, but graph modification can be helpful in creating a copy of the >>> graph with an edge contracted, with an edge deleted, or with a vertex >>> deleted. Oh, and I really dig multiple edges, loops, and edge labels. >>> >> >> I dig all of those things as well. >> >>> >>> I care about the same thing when it comes to sets, and Sage's Set data >>> structure just doesn't cut it. Graphs don't bother too much with the >>> category framework, right? >>> >>> >> Correct. Although we now have a (somewhat dumb) category for graphs, but >> the (di)graph class don't use them. This gives some progress on being able >> to create graph morphisms. We probably should also add a category for >> Matroids as well. >> > > Nonononono! The Sage Set object is TOO SLOW because of categories. Turns > out when generating millions of them, ALL of the time of your code gets > spent in the category framework. At least, that's what happened a few years > ago when I tested this. We can't slow down graphs and matroids in that way. >
I'm not saying we should force the user to use the category implementation, but that we should have one for the user who needs to interact with other parts of Sage. For example, it would allow for a natural interface if you have a morphism between to matroids f: M -> M', then consider the forgetful functor to (abstract) simplicial complexes F, it would push down to a morphism g: F(M) -> F(M'). Also, yes, the category aspects of Sage could probably be faster, and I think the Sage Set is far from being optimized (at least for your purposes). Mutable data structures might also be useful in terms of speed too to have less memory (de)allocations and movement. If you really care about every last drop of speed, then you probably should translate all key functionality/structures to C/C++, use the extra control you have there to optimize, and then use cython to interface with that implementation. At least this is how I would do things. Best, Travis -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
