On Friday, February 1, 2013 1:03:55 PM UTC, jori.ma...@uta.fi wrote: > Should Sage aim to efficient code whenever something is added, or should > we just put in something that works and lock "user interface", i.e. > command or function name, order of arguments etc? >
I don't think we have to chose. It is better to have a slow naive easy to understand algorithm than no algorithm at all. "Now is better than never" And if there is a faster more efficient code, then add it as well even if only works for particular cases. So IMO the best you can do is add both algorithms, the inefficient one and the quick gap one. By default try to use the quick one, and if that fails (if the group cannot be defined in gap, for instance) then revert to the slow method. Incidentally, I think I misunderstood what you wanted to do. Apparently you are trying to identify conjugate *subgroups* of a group G, whilst what I did works for identifying conjugate *elements* of the group. So feel free to implement your wrapper! By the way, the conjugacy classes patches are rebased and combined in a new single patch, and ready for review in http://trac.sagemath.org/sage_trac/ticket/7886 Most of the math was already positively reviewed by David Joyner, and then Jeroen brought up a problem with the UTF encoding (which I think was used only for the special characters in my name), everything seems to work now, and the patchbot is happy, so this one should be an easy review! Cheers, J -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
