Helloooooo Christian. 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 ?...
Thanks, Nathann On 20 June 2013 18:19, Nathann Cohen <nathann.co...@gmail.com> wrote: > 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.
