> > What could possibly be wrong with the existing Poset.hasse_diagram() > method ? >
Nothing. > Well. It's a bit hard to grep the conversions that can be obtained from > the constructors, though :-P > All I wanted to show is that we didn't invent the "to_???" methods which you call "unusual Sage syntax". > MyObject(MyOtherObject) is a cool thing to write when there is no doubt as to how the object should be converted. This becomes a little problematic if the user is not aware that "MyObject" even exists, while she is seeing it in tab completion with the "to_???" method. > Though we already have a P.hasse_diagram() for that. This is not a bad example, DiGraph(P) might be okay to come up with, but would a given user figure out that he should do HasseDiagram(P) in order to get the Hasse diagram (and to import it first, since it's not in the global namespace? > Trying DiGraph(my_poset) to get its associated digraph (hasse diagram) is rather sensible to me, while Partition(my_graph) to get your partition would be totally crazy because there is no natural partition associated with a graph. As I wrote above, DiGraph sounds reasonable to me as well, HasseDiagram much less reasonable, while Partition would indeed be stupid. > all that matters to me is that there is a function from A to B and that's another map for find_stat" Let me emphasize this once more here, if it where only to get it in findstat, there would be no problem at all to patch everything we need, and apply it on top of a fresh Sage - we do that already for other stuff we do not think to be valuable for Sage itself. All I do is arguing that I consider the changes to be valuable for Sage, or equivalently, for other people who use Sage. > but I do think that this .to_partition() and .to_graph() are not valuable to Sage My impression is that you only care because it is "your" graph code. But nevertheless, several people wrote in this thread that they do not like these maps, so I'd suggest to remove them again (I wouldn't call it a majority but I do understand that it is arguable to say "we have a method that provides the connected components, so why should we add another giving their sizes"). > And as I understand why it would be useful for find_stat (you want to add maps, and you can only do so with decorators on functions, i.e. not on constructors) I think that this explanation is right :-P It would have taken me 30 min to undo the changes, and patch them for myself on top of Sage, while this discussion took certainly more time. So I must have had another reason to discuss... > Well, don't want to be forced to run that code when I work on graphs. Is that a problem ? O_o Somehow yes since you consider your negligible disadvantage (as you said yourself) more important than advantages for others. > With the decorator above I wouldn't have to run your code as soon as I call a method which bears your decorator. I'll see if I gonna try to change the implementation, but currently I think of asking if the combinat people want to keep it as it is (and remove the two methods from graphs), or if I just patch it - I don't see why I should spend more time on that... 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.
