Robert Miller wrote: >> 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... >
+1 I'm with Robert. > 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. > +1 too. Jason -- Jason Grout --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
