On Sunday, September 27, 2015 at 1:36:26 PM UTC-5, Nathann Cohen wrote: > > > We can possibly have a function > > > > def cayley_graph(set, generators, operator) > > Yeah yeah, that's what Travis proposed I guess. I just wondered if > there was some special trick to handle these things, as I expect that > it is not the first time some code has to be written twice for + and > for *. Doing it manually with a third function works of course, though > it means (2+1)=3 functions for one feature. Anyaway. The only thing > that still troubles me is this .cayley_graph() + > .additive_cayley_graph(). The naming is terrible. I've fought "review > wars" for the tenth of that. > > This is what I proposed, but having the one with the `operation` input only being a backend function. We should keep with our conventions. Plus having the two names makes which operation you're considering unambiguous with no need to work with choosing a default (which would have to be multiplication for backwards compatibility) and/or something dumb like a string (or boolean) argument.
If you want to consolidate code between additive and multiplicative groups, then you should probably write a method like group_operation(x,y) and have all of the generic code call that (which will have additional overhead of that function call), plus have a common category for the two types of groups unless you want to make backwards incompatible changes. Really, I think trying to do anything like this is too much a can of worms (even without considering backwards compatibility). 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.
