> However, Robert Miller has been notably silent on this topic. We > should try to get him to weigh in before making any sweeping > decisions, since he's (at the very least) the most familiar with the > code.
I have spent months trying to make function calls just like, e.g. G.predecessors(3), as fast as possible. There is still a lot of work left, but things like G.neighbors().in()... or whatever sounds alarmingly to me like extra unnecessary Python layers around a function which you want ABSOLUTELY no Python involved in at all, other than the initial function call. Name changes and aliases I can live with. Extra layers of Python function calls for no reason other than tab completion prettiness, this is really bad. Especially when it's a function as basic as neighbors, which gets used in almost every graph theory algorithm out there. Imagine the future "embarrassing" thread where a 10x speedup is discovered by avoiding this exact approach... As far as it being *possible* to split up graph.py... It's a ten minute job, but nobody's done it. You could split it in three right away by having generic_graph.py, graph.py and digraph.py. -- Robert L. Miller http://www.rlmiller.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
