Hello ! > 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.
The function Poset.to_graph() can be replaced by Graph(the_poset) as Dima pointed out, which makes much more sense in Sage's usual syntax than Poset.to_graph(). You can still do the operation that you need for your research, and this seems to be a much more natural way to implement it in Sage. What do you think ? My comment about your .to_partition() method is that its name does not give the slightest idea of what it does. Do you agree that this objection is valid ? At the very least I think that it should be renamed. > If you feel like > there are too many methods, why not deleting "am" as a shortcut for > "adjacency_matrix", It's a good idea. > or replacing the almost 50 "is_???" by > "has_property(???)", It breaks tab-completion, and it becomes harder to find the list of such properties. > including "antisymmetric" which should rather be > "is_antisymmetric", Oh, good idea. Do you create the patch, or do I write it ? > or replacing all "to_???" by a single method. Tab completion again. > 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. Yeah, I agree with you about antisymmetric and adjacency matrix. > Simply "you want these methods for a 3rd party project, and > I don't like that" is not convincing to me. I pointed out many, many, many times other problems. For instance I relayed Dima's comment that Graph(my_poset) makes more sense. I am pretty sure I wrote that at least 5 times in the emails. But yes, of course, knowing that you add these things in Sage just because you need them for a third party software is something that I do not like at all. I don't consider Sage to be a dependence of find_stat. > 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. Once more, the decorator can stay a decorator and not create a class between the former method and Graph, by just registering the method somewhere else and returning the function it received without changing it. > It might have downsides. But you basically wrote "I don't like it the > way it is done" without giving any reason. Christian please. I made the comment above many many many times. You CAN change your decorator this way, and you have to find a way to add methods to your database without creating method in Sage. If only to be able to add to find_stat all the coercions that exist in our constructors and that do not correspond to methods. For instance if you want to have a map from a binary matrix to a Digraph, or something like that. You cannot think of adding a .to_graph() method to matrices for such a thing ! > An example: You mentioned > that it does run code each time the method is called, and this cannot > be avoided in the current implementation. It *CAN*, if the decorator returns the method exactly as it found it. It can do whatever it wants and register the function and all informations needed in a find_stat module in Sage, i.e. wherever you want but without modifying the method itself. > This is true for ANY method I don't understand that. > You and others asked if it slows down the methods or the > initialization of objects, and we did disprove both. Indeed. And it was obviously necessary to ask this question. I am pretty sure that you did it yourself before you implemented this decorator. > You said that you do not like decorators, that's okay but your > personal preference. Thank you. > 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. Can you tell me why you need this layer ? If you don't, you can simplify your code by removing it. > If you do not like its design (for whatever reason), 1) it forces you to create methods for your maps which is not always justified 2) Currently it adds useless computations to some methods, which does not cost any time but is definitely a bad design .... > feel free to > provide improvements and discuss your improvements Now that you have read them, please give me your opinion on them. > 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). Christian : at the very very very least, and unless there is a way to query find_stat in Sage (and a meaning to that), what you can easily do is make the @combinatorial_map in Sage do *NOTHING*, that is return its input immediately, and patch your own installation of Sage with a definition of a more complex behaviour of combinatorial_map. This way, nobody has to run your find_stat code and you are free to do whatever you want. Otherwise, please consider registering your function into some module and writing decorators which return the functions exactly as it got them. Nathann -- 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.
