Dear all, Thanks Nathann for starting the discussion (though I sometimes think that being a little less aggressive wouldn't hurt).
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): - 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), - 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). - 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), - 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). - 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. Some words on the current implementation: - 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. - 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 sage: class A: ....: def a(self,x): ....: return x ....: sage: class B: ....: @combinatorial_map ....: def b(self,x): ....: return x ....: sage: %timeit AA = A() 1000000 loops, best of 3: 250 ns per loop sage: %timeit BB = B() 1000000 loops, best of 3: 249 ns per loop if there is any better test to check this issue, please do so. 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. 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. "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. 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. Best, 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.
