Hellooooooooooooooooooooooo !! > Thanks Nathann for starting the discussion (though I sometimes think that > being a little less aggressive wouldn't hurt).
Yes, sorry about that. But it takes a lifetime to get people to admit the most elementary things. I mean, my first message contained two lines of which I said "please tell me if you acknowledge this or not", and so far nobody cared even to answer "no" to them. > Let me start with what the positive sides of a combinatorial_map decorator > are for us (and I think several of the combinat people do agree here): Hmm.... I probably agree with all advantages, what find_stat does is nice and useful. But a decorator is not to me a clean way to do it. That' s really the only thing I have been defending all along. Wrapping the method into classes instead of just registering them somewhere, and requiring the addition of new Sage methods just because find_stat needs them. Those are really the only points that I try to make. But I probably agree with all advantages that you list below, it's just totally unrelated. > - we obtain a better image of which maps between combinatorial collections > exist (see in particular the graph at the bottom of > http://www.findstat.org/, and the linked more detailed pdf, this is not only > interesting for FindStat but provides a nice visualization of how many > combinatorial objects in Sage are linked together), That's cool. +1 > - we can thus easier work on completing the picture. Indeed, we implemented > many (~20-30 would be my guess, but I don't know) new maps between > combinatorial objects that are interesting for combinatorialists (even those > not interested in FindStat). That's cool. +1 > - we can automatize checks if maps do indeed map to the proper codomain > (e.g., StandardTableau.conjugate > returned a Tableau, and not a StandardTableau as desired, see #14258), That's cool. +1 > - we can automatize many corner case checks (of course, such checks should > as well go into the doctests, but if > we automatically apply all these maps on hundreds of elements including > corner cases, we already found various bugs in the pre-existing code that > were not captured by the doc tests, see e.g. #14724, #14718, #13624). That's cool. +1 > - we would like more mathematical information to the decorator (though this > is not yet done). This would provide more refined automated requests like > "Which bijections between Dyck paths and NoncrossingSetPartitions are > implemented?". Currently, we can only ask "Which maps from Dyck paths to > NoncrossingSetPartitions are implemented?", but I think that is nice to get > as well. That's cool. +1 But still totally unrelated to the points I try to make. > - I implemented the decorator word by word following the (old) cached_method > decorator, this might have been good or not, but it was the best I was able > to do. Well, just returning the function as it is while registering the decorator's information somewhere seems to be nice. The decorator could even add some information to the docstring so that this information would automatically appear in the doc ! > - Nathann himself tested that the cost of the wrapper when calling the > method is very much negligible, here is a test when creating the object The correct phrasing for this changed since, and will from now on be called masturbation. > if there is any better test to check this issue, please do so. Well, I called the methods while you created the class, but really it's pretty much for free. Only the code has no reason at all to be run when the function is called. And if you want to improve your decorator perhaps you will add more stuff to it, and if you do it like that then it means that the stuff that you will add in the decorator necessarily stays free, from fear that it would add a non-negligible amount of computations when the function is called. Honestly, if you just register the functions somewhere else and do not change them at all I would be very happy. Besides, it would mean that there is a way to add more functions and information to your database WITHOUT creating additional Sage methods, and this would be nice because as Dima said here, Graph(my_poset) makes much more sense that my_poset.to_graph(). And there is this .to_partition() method too, which to me was only added because of find_stat. > Anyway, the current implementation might be good enough to use, or someone > might provide a better implementation, but this is not the point for me, and > - if I understand it right - it's not the point for Nathann either. Two of > his point are yet to be answered/discussed a bit further: > > > "Right now, find_stat seems to work with decorators over Sage's functions. > It is all very nice. But then whenever some addition must be made to > find_stat's combinatorial maps there must be a corresponding Sage function, > and I think that adding functions to Sage just because find_stat needs them > is really going too far. " > > My answer: it is right that - in the current implementation - we need to > implement a map between combinatorial collections in Sage and decorate it > with @combinatorial_map in order to use this map in FindStat. But we only > want to use maps in FindStat that are interesting for mathematicians, and if > this is the case, then it should be very valid to have this map as well in > Sage. In the particular case of .to_partition(), I do not think so. In the particular case of .to_graph() I do not think so either, because Graph(my_poset) makes more sense according to Sage's syntax. Is that a valid objection to the idea that all maps should correspond to Sage methods ? > If anyone is interested I could provide a list with methods we > implemented for (or better in) Sage because we wanted to have them in > FindStat. We can then see if it would have better to implement all these > maps in a different project without allowing Sage users to use them as well. This last sentence ignores the possibility of Graph(my_poset) instead of .to_graph(). > "But it is a website and an independent project, and I don't see why on > earth Sage should now be developped according to find_stat's needs." > > My answer: All we do is to decorate maps between certain combinatorial > collections to provide further information about this map. We then use this > information in FindStat, but this information is not only useful for > FindStat (at least in my opinion), see as well my comments above about the > "positive sides". There might be something not perfect in the actual > implementation, but the so far discussed drawbacks seem to be very little, > compared to the advantage that a user is e.g. not annoyed anymore that the > conjugate of a StandardTableau is not standard anymore, or that there are > now all these new maps between the objects implemented. Anyway, if there is > a better way of achieving such possibilities I am very positive of doing so > (though this will again use someone's time that she might want to use > differently). And: we are Sage users and/or developers, so if we want Sage > to do sth for us that doesn't hurt (@Nathann: except for philosophical > reasons), I don't see the point of not getting Sage doing it for us (as > others did similar things before, according to John Cremona and others > comments earlier on this thread) and for the combinat community. What you do on the math level is nice, find_stat is nice, using Sage to do that too, and Sage benefits from it. Agreed. Now : 1) Is there any need to wrap the methods instead of returning them as they are, while registering the information somewhere. If not, could it be changed ? 2) If you agree that not all find_stat maps should be Sage function (and if you don't please tell me why the two examples above are invalid), could we remove those .to_poset() and .to_partition() things and add the entries to the find_stat database without touching those classes ? > Finally, I think that the combinat part of Sage would have been less > explored without the implementations done in the context of FindStat, and > several combinatorialists only started implementing some maps or new > combinatorial objects because FindStat uses them. So imho, the advantages > outweigh the drawbacks by far, though there might be the point in minimizing > the drawbacks even further. The advantages outweigh the drawbacks, and it may even be possible to have only advantages and no drawbacks. What do you think ? 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.
