Hi Nathan -- > I was thinking of our find_stat battle from one week ago, and I > wondered if you could answer the questions I raised in my answer to > your post. In particular (but not only) about the methods added to > Graph and Poset ?...
Given the level of "shrillness" to which you certainly contributed, I didn't actually plan to answer again. But okay... I keep voting for having the methods added to Graphs and to Posets. I just looked again at the list of methods for graphs, and there are 280 of them. For me (and some others, whichever reason we might have) these two methods are useful for our "mathematics research" and that makes it already a strong case for keeping them. If you feel like there are too many methods, why not deleting "am" as a shortcut for "adjacency_matrix", or replacing the almost 50 "is_???" by "has_property(???)", including "antisymmetric" which should rather be "is_antisymmetric", or replacing all "to_???" by a single method. If there is a majority to delete them, or a particular reason why exactly these methods out of the 280 should be deleted (I do not see either of the two in this discussion currently), I would certainly be okay with doing so. Simply "you want these methods for a 3rd party project, and I don't like that" is not convincing to me. Concerning the general design of the combinatorial_map decorator: I implemented it in a way which did not interfere with other peoples code or usage of Sage AND it made Sage better for several users. I think that makes it a valid contribution. It might have downsides. But you basically wrote "I don't like it the way it is done" without giving any reason. An example: You mentioned that it does run code each time the method is called, and this cannot be avoided in the current implementation. This is true for ANY method in Sage, with or without this decorator. You and others asked if it slows down the methods or the initialization of objects, and we did disprove both. You said that you do not like decorators, that's okay but your personal preference. You do not like that the method gets a thin layer around, but you did not argue why this is (or might become) a problem - so far, the infected methods seemed to be doing okay. If you do not like its design (for whatever reason), feel free to provide improvements and discuss your improvements (I did ask about the combiatorial_map decorator at various occasions, including the mailing list, and no one complained). However such improvements might look like, I want to stay able to ask which methods for a "combinatorial set" are maps to "combinatorial sets" (see the method combinat.combinatorial_map.combinatorial_maps_in_class), and (though this would only come in a little while in the current implementation) I want to tag such maps with mathematical information (okay, the docstring could be used for such information, but this could become complicated since the docstring is then used to provide the user with infos, and to be (partially) machine interpretable at the same time). Cheers, Christian -- 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/groups/opt_out.
