[sage-combinat-devel] Re: redesign combinatorial statistics
Okay here's where I think we are, and my 2 cents in the matter. Simon wants to have a database which stores the map information which is constructed by the decorator @combinatorial_map in order to not have it cause any slowdowns. The question is, "how to do this?" Here's my 2 cents of a solution. The first time the object is called when we want to get the map info, have it iterate over all it's methods and call any method wrapped in @combinatorial_map. The decorator then does: def combinatorial_map(f): # Check if the object's class and the method's name is in the database; # this might not be the right python if (f.self.__class__, f.__name__) in DATABASE: DATABASE.add(...) return f This has the advantage of being dynamic, so it shouldn't hamper startup time, and only occurs the first time the object is created, so repeated uses won't be slow. We could also go one small step further and have an (cython) ABC which does this behavior on initialization. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Diversity to foster sage development
On Wed, May 28, 2014 at 3:56 PM, Paul-Olivier Dehaye wrote: > Out of my confused state after a long day: > I think I still want sage to be a " free open source alternative ", and its > primary audience to be typical users of the Ma's. But the Ma's have indeed > evolved since 2005. Maybe it might be worth, as a start, listing how they > have changed? The goal of the exercise would not be to copycat what they do, > but maybe to understand how the Ma's pipelines work now. Some Ma-related "events" since 2005 that I noticed: * Maplesoft was bought by a Japanese company around 2008... I don't know anything about what ended up happening as a result. * Mathworks bought MuPAD, so now they own computer algebra capabilities (instead of just reselling Maple). iPad app. They also sponsor a radio program on NPR that I here every day :-). * Wolfram Inc. introduced Wolfram|Alpha and Manipulate. iPad app. They are developing a web-based notebook interface, which I think just looks exactly like desktop Mathematica. I don't know if a plugin is required. * Magma made a deal with the Simons Foundation to make Magma available for free to North American academic institutions. John Cannon is still guiding Magma development, which is moving along at a stable rate. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Diversity to foster sage development
Out of my confused state after a long day: I think I still want sage to be a " free open source alternative ", and its primary audience to be typical users of the Ma's. But the Ma's have indeed evolved since 2005. Maybe it might be worth, as a start, listing how they have changed? The goal of the exercise would not be to copycat what they do, but maybe to understand how the Ma's pipelines work now. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Thu, May 29, 2014 at 12:36 AM, William Stein wrote: > On Wed, May 28, 2014 at 3:29 PM, Paul-Olivier Dehaye > wrote: > > In the big wave of emails exchanged today, I sent this one, by accident > to > > the wrong mailing list. I recopy it below: > > > > When I went to pycon, the most important thing I learned is the > importance > > of a diverse community for the development of python. This I learned from > > the top, the board of the Python Software Foundation (cf. Lindberg's > > keynote at pycon, for instance), and saw in action absolutely everywhere. > > > > This diversity is to be understood in a very broad sense: > > - diversity of origins, > > - diversity of genders, > > - diversity of lifestyles, > > - diversity of professional activities, > > - ... > > > > I can egocentrically agree with the PSF on the fourth: the fact that > python > > is tied to so many different fields, ranging from professional software > > development world to all kinds of scientific disciplines, is a major > > selling point for many people. This was the case for me (and William), > > coming from a world of special purpose mathematical software. Relying on > a > > mature language with a diverse ecosystem encourages a wider array of > > contribution to sage. I will posit that a similar motivator was present > for > > many of us who come with previous experience in other languages. > > > > If your software community is not inclusive, you will reject individual > > contributions that might be very interesting (and remain unaware of it), > > and that pattern will lead to larger collaborations having a hard time > > working at the periphery of the core project. This will decrease the > chance > > of the core project recruiting new contributors. And we are talking about > > highly qualified contributions here, contributions that the sage project > > really does not want to end in Magma first. For instance, pick the LMFDB > or > > findstat. How much of their code is written tiptoeing around sage itself, > > and if you make an objective assessment should fit better in sage than in > > their project? Bear in mind that the software was developed itself > already > > tiptoeing around sage's core community (which might be unfair, because a > > community's tone is often defined by just a few individuals who speak > > louder). > > > > You might ask how origin, genders, lifestyles come in play here. Well, > > being inclusive starts simply by being curteous and making people feel at > > ease, and in some particular circumstances being "explicit is better than > > implicit". It might very well be that a queer person finds the python > > community very welcoming (based on objective facts such that one out of > > five tracks at pycon was aimed at promoting diversity in the community, > or > > the diversity of the speakers), that she wants to contribute back, so > much > > so that she decides to organize a python education summit, where > educators > > of students of all backgrounds and ages can share tips on how to build a > > python pipeline together, one that takes anyone between the age of 5 to > the > > age of whatever and turns them into a competent enough programmer that > the > > community is better off from it. Somehow it all works for the better, > > because you have to trust individuals that if they like a project they > will > > contribute to it in a positive way, with their own creativity. > > > > This pipeline exists, and is actively fostered by the Python Software > > Foundation as one of the most important assets of the python ecosystem. > > Contrast the shortsightedness of the academic community wrt the leaky > > pipeline for instance, with the attitude of the PSF described here. There > > is no comparison. > > > > At the same time, my reflections since pycon have led me to understand > that > > it would make sense for things to develop the way they have so far. The > PSF > > has much closer contacts to the corporate world, and it has a much > smaller > > board (which helps make bold decisions more easily than a decentralised > > system of tenured professors). > > > > How are the corporate world connections important? Well, open source > > software is the flagship of Open Innovation, a new and deep trend in > > industry that encourages opening up to the world what was considered > trade > > secrets not long ago (cf. the work of Geor
Re: [sage-combinat-devel] Project: add hundreds of contributors to sage
On Wed, May 28, 2014 at 3:30 PM, Paul-Olivier Dehaye wrote: > Again, in the big wave of emails, this one also got misdirected: > > Hi everyone, > > I am looking for people who want to help me, in one way or another, bring > hundreds of new first time contributors to sage. If I do not find enough > partners, I will look for other more suitable python-based projects. > > The idea would be quite simple: teach python programming around some > mathematics (such as combinatorics) and simultaneously produce code that > would be useful for research and worth including in sage. Two catches: > students are given individual problems to work on, and the course is taught > on Coursera. Motivation for the students would come in various ways: > internships, for instance. Quality of the code would be ensured by > peer-testing the programs. > > If you do not know what Coursera or MOOCs are, you are welcome to take my > upcoming course > https://class.coursera.org/massiveteaching-001 > > If you are interested to play with a MOOC platform yourself, you might want > first to watch the videostream of the 2pm-3pm slot of this conference I am > co-organising on Tuesday: > tinyurl.com/openedx-zurich > as it will help you assess the technical challenges. > > I am looking at a start date for the course of around October-November, and > to bring the discussion off the mailing list (to private) so as to keep an > element of surprise for the students. An obstruction to getting code contributions from "hundreds of new developers" into Sage is the Sage development process via trac, as documented in the Sage Developers guide. I have 40 students in my class this quarter, and have encouraged them all to make contributions to Sage via the standard trac process. Maybe 2 have succeeded, and when I point them out the documentation and look at it myself, I wince.This is not to say that the process is bad -- in fact, for people making major contributions over time, our current system is pretty reasonable overall, and in some ways quite good. But for somebody new to software development who wants to make a few small contributions, e.g., add an example to a docstring, it is not definitely optimal. One possible approach for your course would be to do everything through pull requests on github, which are ridiculously easy to make. Then we (i.e., some expert sage developers) would aggregate some of those contributions into a smaller number of trac tickets, which would get included in Sage in the traditional way. This approach would be nice since it wouldn't require changing anything about Sage development or infrastructure, but would allow us to try out new approaches, which might later influence the Sage development process. It would be interesting to think about "low hanging fruit" sage development projects. There's a *ton* of obvious things one might want to implement for Sage... which are now already done well. E.g., I had students in my class tell me what they wanted to do their final projects on, and in the majority of cases I had to point out that what they wanted to do was already done in Sage well (or at least done many times over well in Python). They often still did the projects, but making it clear that it was for-fun toy code. However, one example is applying transforms to a 2d plot in Sage -- that seems not done, though we have 3d transforms in Sage. I know trac is supposed to have "beginning tickets", but when I send beginners to trac, they invariably claim to find nothing to do. So a big list of low hanging fruit that would make sense to implement in Sage would be useful. Again, an example is: - implement functions like rotate, translate, etc., for 2d graphics objects, like the corresponding 3d functions. That said, Sage is getting mature enough at the easy things that I wouldn't be surprised if somebody responds to this email and says -- oh, that's easy, via converting the plot to matplotlib, or something... Of course when I think about more advanced mathematics, Sage has a million obvious gaps to fill, and is extremely immature with a huge amount of low hanging fruit. But this is all grad student level stuff. -- William > > Let me know! > > Paul > > Paul-Olivier Dehaye > SNF Professor of Mathematics > University of Zurich > skype: lokami_lokami (preferred) > phone: +41 76 407 57 96 > chat: pauloliv...@gmail.com > twitter: podehaye > freenode irc: pdehaye > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.
Re: [sage-combinat-devel] Diversity to foster sage development
On Wed, May 28, 2014 at 3:29 PM, Paul-Olivier Dehaye wrote: > In the big wave of emails exchanged today, I sent this one, by accident to > the wrong mailing list. I recopy it below: > > When I went to pycon, the most important thing I learned is the importance > of a diverse community for the development of python. This I learned from > the top, the board of the Python Software Foundation (cf. Lindberg's > keynote at pycon, for instance), and saw in action absolutely everywhere. > > This diversity is to be understood in a very broad sense: > - diversity of origins, > - diversity of genders, > - diversity of lifestyles, > - diversity of professional activities, > - ... > > I can egocentrically agree with the PSF on the fourth: the fact that python > is tied to so many different fields, ranging from professional software > development world to all kinds of scientific disciplines, is a major > selling point for many people. This was the case for me (and William), > coming from a world of special purpose mathematical software. Relying on a > mature language with a diverse ecosystem encourages a wider array of > contribution to sage. I will posit that a similar motivator was present for > many of us who come with previous experience in other languages. > > If your software community is not inclusive, you will reject individual > contributions that might be very interesting (and remain unaware of it), > and that pattern will lead to larger collaborations having a hard time > working at the periphery of the core project. This will decrease the chance > of the core project recruiting new contributors. And we are talking about > highly qualified contributions here, contributions that the sage project > really does not want to end in Magma first. For instance, pick the LMFDB or > findstat. How much of their code is written tiptoeing around sage itself, > and if you make an objective assessment should fit better in sage than in > their project? Bear in mind that the software was developed itself already > tiptoeing around sage's core community (which might be unfair, because a > community's tone is often defined by just a few individuals who speak > louder). > > You might ask how origin, genders, lifestyles come in play here. Well, > being inclusive starts simply by being curteous and making people feel at > ease, and in some particular circumstances being "explicit is better than > implicit". It might very well be that a queer person finds the python > community very welcoming (based on objective facts such that one out of > five tracks at pycon was aimed at promoting diversity in the community, or > the diversity of the speakers), that she wants to contribute back, so much > so that she decides to organize a python education summit, where educators > of students of all backgrounds and ages can share tips on how to build a > python pipeline together, one that takes anyone between the age of 5 to the > age of whatever and turns them into a competent enough programmer that the > community is better off from it. Somehow it all works for the better, > because you have to trust individuals that if they like a project they will > contribute to it in a positive way, with their own creativity. > > This pipeline exists, and is actively fostered by the Python Software > Foundation as one of the most important assets of the python ecosystem. > Contrast the shortsightedness of the academic community wrt the leaky > pipeline for instance, with the attitude of the PSF described here. There > is no comparison. > > At the same time, my reflections since pycon have led me to understand that > it would make sense for things to develop the way they have so far. The PSF > has much closer contacts to the corporate world, and it has a much smaller > board (which helps make bold decisions more easily than a decentralised > system of tenured professors). > > How are the corporate world connections important? Well, open source > software is the flagship of Open Innovation, a new and deep trend in > industry that encourages opening up to the world what was considered trade > secrets not long ago (cf. the work of Georg von Krogh, for instance). Open > Innovation makes more business sense if the community that watches those > overtures is wider, because it is then more likely to come up with new > ideas that would have never arisen within closed walls of the company. > Following perfect logical arguments, after some stage the only way to grow > a community is to make it more diverse (in the broad sense described > above), and companies realised that too: promoting diversity also makes > business sense. Now this idea is flowing back to open source software, like > the python ecosystem, and it is only to the credit of the PSF to take this > stance. This is very different from other languages apparently. > > Maybe my perspective of the python community was skewed by the fact that > pycon is a US-centric conference. I would be curious to see how
[sage-combinat-devel] Project: add hundreds of contributors to sage
Again, in the big wave of emails, this one also got misdirected: Hi everyone, I am looking for people who want to help me, in one way or another, bring hundreds of new first time contributors to sage. If I do not find enough partners, I will look for other more suitable python-based projects. The idea would be quite simple: teach python programming around some mathematics (such as combinatorics) and simultaneously produce code that would be useful for research and worth including in sage. Two catches: students are given individual problems to work on, and the course is taught on Coursera. Motivation for the students would come in various ways: internships, for instance. Quality of the code would be ensured by peer-testing the programs. If you do not know what Coursera or MOOCs are, you are welcome to take my upcoming course https://class.coursera.org/massiveteaching-001 If you are interested to play with a MOOC platform yourself, you might want first to watch the videostream of the 2pm-3pm slot of this conference I am co-organising on Tuesday: tinyurl.com/openedx-zurich as it will help you assess the technical challenges. I am looking at a start date for the course of around October-November, and to bring the discussion off the mailing list (to private) so as to keep an element of surprise for the students. Let me know! Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Diversity to foster sage development
In the big wave of emails exchanged today, I sent this one, by accident to the wrong mailing list. I recopy it below: When I went to pycon, the most important thing I learned is the importance of a diverse community for the development of python. This I learned from the top, the board of the Python Software Foundation (cf. Lindberg's keynote at pycon, for instance), and saw in action absolutely everywhere. This diversity is to be understood in a very broad sense: - diversity of origins, - diversity of genders, - diversity of lifestyles, - diversity of professional activities, - ... I can egocentrically agree with the PSF on the fourth: the fact that python is tied to so many different fields, ranging from professional software development world to all kinds of scientific disciplines, is a major selling point for many people. This was the case for me (and William), coming from a world of special purpose mathematical software. Relying on a mature language with a diverse ecosystem encourages a wider array of contribution to sage. I will posit that a similar motivator was present for many of us who come with previous experience in other languages. If your software community is not inclusive, you will reject individual contributions that might be very interesting (and remain unaware of it), and that pattern will lead to larger collaborations having a hard time working at the periphery of the core project. This will decrease the chance of the core project recruiting new contributors. And we are talking about highly qualified contributions here, contributions that the sage project really does not want to end in Magma first. For instance, pick the LMFDB or findstat. How much of their code is written tiptoeing around sage itself, and if you make an objective assessment should fit better in sage than in their project? Bear in mind that the software was developed itself already tiptoeing around sage's core community (which might be unfair, because a community's tone is often defined by just a few individuals who speak louder). You might ask how origin, genders, lifestyles come in play here. Well, being inclusive starts simply by being curteous and making people feel at ease, and in some particular circumstances being "explicit is better than implicit". It might very well be that a queer person finds the python community very welcoming (based on objective facts such that one out of five tracks at pycon was aimed at promoting diversity in the community, or the diversity of the speakers), that she wants to contribute back, so much so that she decides to organize a python education summit, where educators of students of all backgrounds and ages can share tips on how to build a python pipeline together, one that takes anyone between the age of 5 to the age of whatever and turns them into a competent enough programmer that the community is better off from it. Somehow it all works for the better, because you have to trust individuals that if they like a project they will contribute to it in a positive way, with their own creativity. This pipeline exists, and is actively fostered by the Python Software Foundation as one of the most important assets of the python ecosystem. Contrast the shortsightedness of the academic community wrt the leaky pipeline for instance, with the attitude of the PSF described here. There is no comparison. At the same time, my reflections since pycon have led me to understand that it would make sense for things to develop the way they have so far. The PSF has much closer contacts to the corporate world, and it has a much smaller board (which helps make bold decisions more easily than a decentralised system of tenured professors). How are the corporate world connections important? Well, open source software is the flagship of Open Innovation, a new and deep trend in industry that encourages opening up to the world what was considered trade secrets not long ago (cf. the work of Georg von Krogh, for instance). Open Innovation makes more business sense if the community that watches those overtures is wider, because it is then more likely to come up with new ideas that would have never arisen within closed walls of the company. Following perfect logical arguments, after some stage the only way to grow a community is to make it more diverse (in the broad sense described above), and companies realised that too: promoting diversity also makes business sense. Now this idea is flowing back to open source software, like the python ecosystem, and it is only to the credit of the PSF to take this stance. This is very different from other languages apparently. Maybe my perspective of the python community was skewed by the fact that pycon is a US-centric conference. I would be curious to see how it compares to EuroPython for those aspects, but will be unable to attend. All this is especially true I would think for software like sage, which aims to be a replacement to the large CAS software companies. Look
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
I think an argument that this function is badly named is very sensible. Maybe a better name would be "to_component_sizes". Why not just try changing the name, and see how much work that is for the findstat group to adapt. It might be that this does not want to be named, after all, and that simply an unnamed method needs to be registered. Do you feel that you own the class "Graph"? And get to decide what is interesting and what is not relating to Graphs? If so, then indeed there is a problem. What bothers you particularly? To see those methods in the code? To see it appear when you press ? Clarifying that part would help making everyone happy. Paul On Wed, May 28, 2014 at 9:52 PM, Nathann Cohen wrote: > Yo ! > > > Currently that ticket's description is in complete > > contradiction to what you seem to describe on the mailing list (which > seems > > more sensible to me). In particular the title of the ticket is "Rename" > > while the last line says "remove". > > Not my doing. When I posted my last comment on this ticket I set it to > "positive_review" and "wontfix" because I gave up. I cannot do anything > against a reviewer like you. > Afterwards Ralf changed some stuff, then you set the ticket to > needs_review, then it was set to needs_work by somebody else. Honestly it > is not my ticket anymore, do what you want with it. > > About the difference you see between my ticket, which said "remove the > function" and what I said here in my previous post : > I had not noticed before that having a hidden function was actually a nice > middle-ground. You can create functions "for semantics only" if it is > useful, but this is an "internal mechanism" of Sage. If you need a function > which transforms a Graph into a partition of integer to this end it is > good, and you can name it Graph._to_partition if you like, but > Graph.to_partition means that the function is unclear and not something > users should see. And even if a better name is to be found, I would still > claim that this function is really not useful to users (though it may be > useful for the databases you want to build), and as such has nothing to do > in the (already quite crowded) list of graph functions. > > So, yeah. Basically, I had not noticed that having a hidden function with > a decorator on it (named to_partition if needed) was a good middle ground. > > > As long as this is the case, Nathann's arguments are incoherent and > > contradictory, and any conversation on the list will turn in circles. > > > > My summary assessment so far is that Nathann is wrong, the > implementation by > > findstat of their ideas is poor, and the burden is on all of us to > improve > > it, particularly those who care the most. That's the way sage development > > works, as far as I understand it. Maybe I will be swayed by good > arguments > > from Nathann, who has opened the ticket. I am genuinely keeping an open > mind > > about implementation. I want him to improve what's there, not remove, if > he > > cares enough. > > Whatever. > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Yo ! > Currently that ticket's description is in complete > contradiction to what you seem to describe on the mailing list (which seems > more sensible to me). In particular the title of the ticket is "Rename" > while the last line says "remove". Not my doing. When I posted my last comment on this ticket I set it to "positive_review" and "wontfix" because I gave up. I cannot do anything against a reviewer like you. Afterwards Ralf changed some stuff, then you set the ticket to needs_review, then it was set to needs_work by somebody else. Honestly it is not my ticket anymore, do what you want with it. About the difference you see between my ticket, which said "remove the function" and what I said here in my previous post : I had not noticed before that having a hidden function was actually a nice middle-ground. You can create functions "for semantics only" if it is useful, but this is an "internal mechanism" of Sage. If you need a function which transforms a Graph into a partition of integer to this end it is good, and you can name it Graph._to_partition if you like, but Graph.to_partition means that the function is unclear and not something users should see. And even if a better name is to be found, I would still claim that this function is really not useful to users (though it may be useful for the databases you want to build), and as such has nothing to do in the (already quite crowded) list of graph functions. So, yeah. Basically, I had not noticed that having a hidden function with a decorator on it (named to_partition if needed) was a good middle ground. > As long as this is the case, Nathann's arguments are incoherent and > contradictory, and any conversation on the list will turn in circles. > > My summary assessment so far is that Nathann is wrong, the implementation by > findstat of their ideas is poor, and the burden is on all of us to improve > it, particularly those who care the most. That's the way sage development > works, as far as I understand it. Maybe I will be swayed by good arguments > from Nathann, who has opened the ticket. I am genuinely keeping an open mind > about implementation. I want him to improve what's there, not remove, if he > cares enough. Whatever. Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
At some point we will need a summary, or to use something better than mailing lists to discuss this. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 9:46 PM, Paul-Olivier Dehaye < paul-olivier.deh...@math.uzh.ch> wrote: > > - Nathann is arguing that no empty methods/classes should be present. > I think he is, and add Vincent too (cf. previous email of his). > > Absolutely noone wants unefficient code. If there is a clear way to > improve, let's do it. But burden is on all of us. > > To be clear, I want to have this semantic information in the code. > > There are many reasons for this, here is one more: it provides an > intermediate step for a person joining sage between a typo fix and > implementing their first function, welcoming microcontributions. I think > decorators would be very suitable for this, but am open to alternate > suggestions. > > > Would this be a short-term solution? > Sure! > > Paul > > > > > > Paul-Olivier Dehaye > SNF Professor of Mathematics > University of Zurich > skype: lokami_lokami (preferred) > phone: +41 76 407 57 96 > chat: pauloliv...@gmail.com > twitter: podehaye > freenode irc: pdehaye > > > On Wed, May 28, 2014 at 8:47 PM, Simon King wrote: > >> Hi Paul, >> >> On 2014-05-28, Paul-Olivier Dehaye >> wrote: >> > Two comments: >> > - Nathann is arguing that no empty methods/classes should be present. >> >> Is he? Sorry, then this is a point where Nathann and I do not agree. I >> find abstract methods useful. I thought that his main point was: Don't >> be intrusive! Do not make code of some people slower just because other >> people care about the mathematical properties of some methods. And from >> my perspective, the discussion is (or should be) only about the >> question: How to care about the mathematical properties without slowing >> down other peoples code. >> >> > - They are not building a database. They are putting tags in the code >> that >> > allow them at runtime to build something that amounts to a database. >> It's >> > not that different to the category framework in some way, which is >> encoding >> > a lot of data via code constructions >> >> There was in fact some discussion at #10963 about the question whether it >> is >> a good idea that the new category-with-axiom framework encodes a >> fully-grown >> would-be-database (by this, I mean something that amounts to a database) >> by >> purely local data and naming conventions. >> >> I'd say: If they are putting tags in the code then they *do* create a >> (would-be-)database, whether they want it or not. >> >> > I am not arguing that what findstat does with a decorator is the best. A >> > flagged decorator that does nothing most of the time is better than what >> > they do. But a full-on database is, as a short term solution, heading in >> > the wrong direction. >> >> Do I understand correctly: You would not like that the >> @combinatorial_map decorator constructs a database at startup time? I >> think that's a valid concern. >> >> We could try to be clever and introduce an environment variable (or >> commandline argument) such that @combinatorial_map creates a database >> when this variable is set, and otherwise does nothing at all. >> >> Hence, people who care about the implicit would-be-database encoded in >> the flags could obtain them by explicit request, and all other people >> would not be affected at all. >> >> Would this be a short-term solution? Also from Nathann's perspective? >> >> Cheers, >> Simon >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-combinat-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-combinat-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-combinat-devel@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/sage-combinat-devel. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> - Nathann is arguing that no empty methods/classes should be present. I think he is, and add Vincent too (cf. previous email of his). Absolutely noone wants unefficient code. If there is a clear way to improve, let's do it. But burden is on all of us. To be clear, I want to have this semantic information in the code. There are many reasons for this, here is one more: it provides an intermediate step for a person joining sage between a typo fix and implementing their first function, welcoming microcontributions. I think decorators would be very suitable for this, but am open to alternate suggestions. > Would this be a short-term solution? Sure! Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 8:47 PM, Simon King wrote: > Hi Paul, > > On 2014-05-28, Paul-Olivier Dehaye > wrote: > > Two comments: > > - Nathann is arguing that no empty methods/classes should be present. > > Is he? Sorry, then this is a point where Nathann and I do not agree. I > find abstract methods useful. I thought that his main point was: Don't > be intrusive! Do not make code of some people slower just because other > people care about the mathematical properties of some methods. And from > my perspective, the discussion is (or should be) only about the > question: How to care about the mathematical properties without slowing > down other peoples code. > > > - They are not building a database. They are putting tags in the code > that > > allow them at runtime to build something that amounts to a database. It's > > not that different to the category framework in some way, which is > encoding > > a lot of data via code constructions > > There was in fact some discussion at #10963 about the question whether it > is > a good idea that the new category-with-axiom framework encodes a > fully-grown > would-be-database (by this, I mean something that amounts to a database) by > purely local data and naming conventions. > > I'd say: If they are putting tags in the code then they *do* create a > (would-be-)database, whether they want it or not. > > > I am not arguing that what findstat does with a decorator is the best. A > > flagged decorator that does nothing most of the time is better than what > > they do. But a full-on database is, as a short term solution, heading in > > the wrong direction. > > Do I understand correctly: You would not like that the > @combinatorial_map decorator constructs a database at startup time? I > think that's a valid concern. > > We could try to be clever and introduce an environment variable (or > commandline argument) such that @combinatorial_map creates a database > when this variable is set, and otherwise does nothing at all. > > Hence, people who care about the implicit would-be-database encoded in > the flags could obtain them by explicit request, and all other people > would not be affected at all. > > Would this be a short-term solution? Also from Nathann's perspective? > > Cheers, > Simon > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
@Nathann, Simon: There is certainly a lot of misunderstandings between all of us. Both ways. The discussion was started because of a suggestion, turned into a ticket written by Nathann. Currently that ticket's description is in complete contradiction to what you seem to describe on the mailing list (which seems more sensible to me). In particular the title of the ticket is "Rename" while the last line says "remove". As long as this is the case, Nathann's arguments are incoherent and contradictory, and any conversation on the list will turn in circles. My summary assessment so far is that Nathann is wrong, the implementation by findstat of their ideas is poor, and the burden is on all of us to improve it, particularly those who care the most. That's the way sage development works, as far as I understand it. Maybe I will be swayed by good arguments from Nathann, who has opened the ticket. I am genuinely keeping an open mind about implementation. I want him to improve what's there, not remove, if he cares enough. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 7:00 PM, Nathann Cohen wrote: > Yo ! > > > I agree 100% with your summary, Simon, except that > > 1) Nathann will have to say himself whether he agrees or not; > > I think that the first time I said it was on the 20/6/2013 (one year ago): > > https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/u7f4X-cLlrsJ > Quote : "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 !" > > Then, I repeated it (same day one year ago) > https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ > > I added yesterday a link toward the link above : > https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/wiEpg-eCnYAJ > > Which was right after mentionning this idea again : > https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/BJ0WMYjmKJ0J > > I mean... > I don't know > Yeah... I am pretty sure that I did my job and that I mentionned the > idea. What more can I do ? > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi Vincent
The wikipedia definition of flaming has the words "hostile" and
"insulting". I have certainly been hostile towards Nathann, and have
explicitly explained to him early on why he was wrong and why I was being
hostile. It is part of academic discourse to have heated discussions,
because we are always exploring new ideas. I was hoping this would have put
some sense into him and made sure to hold my ground, rather than letting
the issue drop as I have done in previous discussions. His reactions have
only confirmed that I was on the right track to deal with him: he has never
asked for references, doesn't seem to have looked at those I pointed out,
and eventually insulted me. This is completely unprofessional behaviour. I
even tried to offer to discuss this in private to prevent him further
harming himself. So in summary, I have been hostile and he was both hostile
and insulting.
If you feel that I have been insulting somewhere, PLEASE point me to where,
I will look and immediately apologise if I agree with you.
I will concede that I was waiting for the right moment to jump in on the
mailing list, and that this was planned. Maybe some might be shocked at
this, but again it fits in a larger context that spans at least a couple
years. Again, that's a fair tactic for academics.
This is concerning my attitude towards Nathann. Towards you, I very much
hope I wasn't insulting or hostile (but it is hard to pin down Nathann's
arguments, it is a moving target, so you might have felt associated to some
of the hostility). Your attitude has only been constructive, and in fact
early on I suggested we keep the positivity to your thread. Let me
blanket-apologise if I have insulted or been hostile to you. That was
absolutely not my intent, quite the opposite.
Of course, it is unpleasant for everyone, I am also sorry for that. But
sometimes people need to be put in their place.
Now back to the "content".
I am asking Nathann's opinion because I don't want to go through the same
again and again.
And, reading your 2) opinion, you disagree with Simon (but there I am
reading in an email he sent after yours).
Paul
Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye
On Wed, May 28, 2014 at 6:56 PM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:
> Hi Paul,
>
> 2014-05-28 17:42 UTC+02:00, Paul-Olivier Dehaye
> :
> > I agree 100% with your summary, Simon, except that
> > 1) Nathann will have to say himself whether he agrees or not;
>
> Please at some point stop the flame.
>
> > 2) A decision should be made whether it is valid to introduce lots of
> empty
> > methods and classes simply for the semantic decorators that will be
> added.
>
> It is not. Could you give an example of what you are thinking about ?
> In my mind it would be seomthing like the natural injection ZZ ->
> QQ... but this is already there
> {{{
> sage: QQ.convert_map_from(ZZ)
> Natural morphism:
> From: Integer Ring
> To: Rational Field
> }}}
> So there is no need to create an empty method .as_rational() on each
> integer. If you want a trivial function in your database then
> implement it as a Morphism. Or better as Simon said: put in the
> database what is needed to actually build the Morphism.
>
> Vincent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-combinat-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-combinat-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-combinat-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-combinat-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
OK, great, thanks for clarifying! Am Mittwoch, 28. Mai 2014 20:53:36 UTC+2 schrieb Simon King: > > Hi Martin, > > On 2014-05-28, 'Martin R' via sage-combinat-devel < > sage-comb...@googlegroups.com > wrote: > >> E.g., it should know domain and codomain, and it should know > >> what category it belongs to. I think it makes sense to let a morphism > >> know whether it is injective or surjective. However, additional > >> information that is certainly interesting to researchers (e.g.: "Was > first > >> defined by John Doe in his seminal paper in Journal of Applied > >> Irrelevance") clearly should not be stored as an attribute of a > morphism. > >> > > > > I do not see any reason why such information should not be stored > somewhere > > within sage, possibly in form of a database. Could you please explain? > > I clearly said: "... should not be stored as an attribute OF A > MORPHISM". I also clearly said "... is certainly interesting to > researchers", hence (which I said in other parts of the post) it would > certainly be worth-while to store somewhere in Sage. I just doubt that > storing it locally as an attribute of a morphism is a good idea. > > Best regards, > Simon > > > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hello !!! > Is he? Sorry, then this is a point where Nathann and I do not agree. I don't even know what I think anymore. With the turn that events take, I think I don't even need to think anymore. I think that I will think what you think I think, it is much easier for me. > find abstract methods useful. I thought that his main point was: Don't > be intrusive! Do not make code of some people slower just because other > people care about the mathematical properties of some methods. And from > my perspective, the discussion is (or should be) only about the > question: How to care about the mathematical properties without slowing > down other peoples code. Yep. I also defended that "respecting other people's code" also meant "not adding method to the classes they use if the method is not useful for them". If it is only for internal stuff, a hidden (beginning with a '_' works for everybody...). But that was a long time ago and I gave up on #16403. > Do I understand correctly: You would not like that the > @combinatorial_map decorator constructs a database at startup time? I > think that's a valid concern. > > We could try to be clever and introduce an environment variable (or > commandline argument) such that @combinatorial_map creates a database > when this variable is set, and otherwise does nothing at all. > > Hence, people who care about the implicit would-be-database encoded in > the flags could obtain them by explicit request, and all other people > would not be affected at all. > > Would this be a short-term solution? Also from Nathann's perspective? Nathann's perspective (I just asked him) was given in this earlier message about implementing . a global variable to enable/disable this feature. https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/-A5k4K4A9QMJ But it was answered immediately afterward : "About Nathan's suggestion to have a flag, I don't know if it's such a good idea. The idea is to provide this semantic information to any user of Sage not machines." Truth is, the decorator I have in mind only copies the function and the arguments to some global "list" (that's all) and I am not scared of this cost, given that it is only paid when the class is loaded. Then, there can be a longer computation occurring the first time the database is queried, and this hardly matters for it is only paid for those who actually want to use the db information. Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
Hi Martin, On 2014-05-28, 'Martin R' via sage-combinat-devel wrote: >> E.g., it should know domain and codomain, and it should know >> what category it belongs to. I think it makes sense to let a morphism >> know whether it is injective or surjective. However, additional >> information that is certainly interesting to researchers (e.g.: "Was first >> defined by John Doe in his seminal paper in Journal of Applied >> Irrelevance") clearly should not be stored as an attribute of a morphism. >> > > I do not see any reason why such information should not be stored somewhere > within sage, possibly in form of a database. Could you please explain? I clearly said: "... should not be stored as an attribute OF A MORPHISM". I also clearly said "... is certainly interesting to researchers", hence (which I said in other parts of the post) it would certainly be worth-while to store somewhere in Sage. I just doubt that storing it locally as an attribute of a morphism is a good idea. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
Hi Paul, On 2014-05-28, Paul-Olivier Dehaye wrote: > Two comments: > - Nathann is arguing that no empty methods/classes should be present. Is he? Sorry, then this is a point where Nathann and I do not agree. I find abstract methods useful. I thought that his main point was: Don't be intrusive! Do not make code of some people slower just because other people care about the mathematical properties of some methods. And from my perspective, the discussion is (or should be) only about the question: How to care about the mathematical properties without slowing down other peoples code. > - They are not building a database. They are putting tags in the code that > allow them at runtime to build something that amounts to a database. It's > not that different to the category framework in some way, which is encoding > a lot of data via code constructions There was in fact some discussion at #10963 about the question whether it is a good idea that the new category-with-axiom framework encodes a fully-grown would-be-database (by this, I mean something that amounts to a database) by purely local data and naming conventions. I'd say: If they are putting tags in the code then they *do* create a (would-be-)database, whether they want it or not. > I am not arguing that what findstat does with a decorator is the best. A > flagged decorator that does nothing most of the time is better than what > they do. But a full-on database is, as a short term solution, heading in > the wrong direction. Do I understand correctly: You would not like that the @combinatorial_map decorator constructs a database at startup time? I think that's a valid concern. We could try to be clever and introduce an environment variable (or commandline argument) such that @combinatorial_map creates a database when this variable is set, and otherwise does nothing at all. Hence, people who care about the implicit would-be-database encoded in the flags could obtain them by explicit request, and all other people would not be affected at all. Would this be a short-term solution? Also from Nathann's perspective? Cheers, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
> > E.g., it should know domain and codomain, and it should know > what category it belongs to. I think it makes sense to let a morphism > know whether it is injective or surjective. However, additional > information that is certainly interesting to researchers (e.g.: "Was first > defined by John Doe in his seminal paper in Journal of Applied > Irrelevance") clearly should not be stored as an attribute of a morphism. > I do not see any reason why such information should not be stored somewhere within sage, possibly in form of a database. Could you please explain? Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi Vivianne,
2014-05-28 19:32 UTC+02:00, Viviane Pons :
> I think we all agree on this idea now (that the decorator should not wrap
> the method), so there is no point in keeping the argument.
>
> Still, I have asked a few questions on which I'd like you guys opinions:
>
> - what's the best way to store this information? Nathan and Simon mentioned
> database, would this be a run time database? Or something persistent?
I am not sure a real database (e.g. sql or similar) would be the best.
The real question is how many maps you would like to handle ? If the
answer is below 5 I would go for a pure Python datastructure
(dict, set and so).
> - Where to put the method to get the maps, right now it is a function
> hidden in some folder. I would like people to be able to see it when
> they're on the object, but it seems silly to add it manually to the object
> and yet, it shouldn't be on every object...
For me, it would makes sense on parents directly
{{{
sage: Permutations().known_maps_to(Partitions())
[...]
}}}
And in the methods known_maps_to and known_maps_from there should be
pointer on how to feed the database with more maps. But I would charge
the elements with that.
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics
I think we all agree on this idea now (that the decorator should not wrap the method), so there is no point in keeping the argument. Still, I have asked a few questions on which I'd like you guys opinions: - what's the best way to store this information? Nathan and Simon mentioned database, would this be a run time database? Or something persistent? - Where to put the method to get the maps, right now it is a function hidden in some folder. I would like people to be able to see it when they're on the object, but it seems silly to add it manually to the object and yet, it shouldn't be on every object... Cheers Viviane 2014-05-28 19:00 GMT+02:00 Nathann Cohen : > Yo ! > > > I agree 100% with your summary, Simon, except that > > 1) Nathann will have to say himself whether he agrees or not; > > I think that the first time I said it was on the 20/6/2013 (one year ago): > > https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/u7f4X-cLlrsJ > Quote : "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 !" > > Then, I repeated it (same day one year ago) > https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ > > I added yesterday a link toward the link above : > https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/wiEpg-eCnYAJ > > Which was right after mentionning this idea again : > https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/BJ0WMYjmKJ0J > > I mean... > I don't know > Yeah... I am pretty sure that I did my job and that I mentionned the > idea. What more can I do ? > > 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-de...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi Paul,
2014-05-28 17:42 UTC+02:00, Paul-Olivier Dehaye
:
> I agree 100% with your summary, Simon, except that
> 1) Nathann will have to say himself whether he agrees or not;
Please at some point stop the flame.
> 2) A decision should be made whether it is valid to introduce lots of empty
> methods and classes simply for the semantic decorators that will be added.
It is not. Could you give an example of what you are thinking about ?
In my mind it would be seomthing like the natural injection ZZ ->
QQ... but this is already there
{{{
sage: QQ.convert_map_from(ZZ)
Natural morphism:
From: Integer Ring
To: Rational Field
}}}
So there is no need to create an empty method .as_rational() on each
integer. If you want a trivial function in your database then
implement it as a Morphism. Or better as Simon said: put in the
database what is needed to actually build the Morphism.
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Yo ! > I agree 100% with your summary, Simon, except that > 1) Nathann will have to say himself whether he agrees or not; I think that the first time I said it was on the 20/6/2013 (one year ago): https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/u7f4X-cLlrsJ Quote : "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 !" Then, I repeated it (same day one year ago) https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ I added yesterday a link toward the link above : https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/wiEpg-eCnYAJ Which was right after mentionning this idea again : https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/BJ0WMYjmKJ0J I mean... I don't know Yeah... I am pretty sure that I did my job and that I mentionned the idea. What more can I do ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi Christian, 2014-05-28 15:21 UTC+02:00, Christian Stump : >> The second step would be to think how to add semantic to the map. Part >> of is already managed by the axioms/categories (for example a Morphism > --> How do you think "more semantic" should be implemented? As a dict > with some conventions for keys and values? Here I am not sure. As Simon pointed out we do not want to start having tons of informations attached to maps... but for most of them I would be in favor of methods (some of them my be trivial as "return True" and some others might involve computations). > --> What if I want to give properties that depend on input parameter > like the length of the permutation? Say I look at the map from > Permutations(n) to itself given by composition with the long cycle > (1..n), and now want to add the semantic information that it has order > n? In that very particular case, I would implement a generic class InteriorAutomorphism (that is an element of the group of the automorphisms of a given group). Then the order would simply be obtained through the method .order() that exists for any group element. Then it is up to you to see which of these interior automorphisms you want to add to your database. > --> Is there a way to implement your ideas such that the lines of code > I need to touch in order to turn a method into a map is right where > the method is implemented? decorator is exactly the kind of objects design to do that. Vincent -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
I agree 100% with your summary, Simon, except that 1) Nathann will have to say himself whether he agrees or not; 2) A decision should be made whether it is valid to introduce lots of empty methods and classes simply for the semantic decorators that will be added. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 5:32 PM, Simon King wrote: > Hi Paul, > > On 2014-05-28, Paul-Olivier Dehaye > wrote: > > Christian's point is key. The absolute hardest problem to solve is where > to > > anchor semantic information so that others can contribute to it easily, > > ... > > Right now, by lack of a better place, it is put in sage. > > I think you miss the point of what Nathann and I try to say. > > I think Nathann agrees that it is a reasonable idea to have a > @combinatorial_map > decorator in front of a method (I do agree), provided that it gives useful > information to some people (this is the case now), and provided that it > does not have a negative impact for people who don't use this > information---and currently it *does* have a negative impact, because of > a slow-down in potentially time-critical methods. > > Last attempt before leaving office: > - Currently we have a lose-lose situation: When people put > @combinatorial_map, then it has a negative impact to some other > people (the slow-down), and it is difficult to use the added information > for those who want to do proper queries. > - We should better have a win-win situation: When people put > @combinatorial_map, then it should not change the method (to not > slow-down stuff), and the added information should be accessible to > queries in a reasonable way. > > Cheers, > Simon > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Two comments: - Nathann is arguing that no empty methods/classes should be present. Which means to me that he doesn t see the value of semantic information in itself - They are not building a database. They are putting tags in the code that allow them at runtime to build something that amounts to a database. It's not that different to the category framework in some way, which is encoding a lot of data via code constructions (partially redundant work: cf http://nforum.mathforge.org/discussion/2490/what-would-you-want-from-a-higher-categorical-database/#Item_0). In any case, the way findstat does things, they have the potential to construct a database. The point is that they allow me to reuse their work to easily build my own database on top, that does something different. I am not arguing that what findstat does with a decorator is the best. A flagged decorator that does nothing most of the time is better than what they do. But a full-on database is, as a short term solution, heading in the wrong direction. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 5:23 PM, Simon King wrote: > Hi Christian, > > On 2014-05-28, Christian Stump wrote: > > But how am I then convincing > > someone knowing that information to add that information there? > > Ask him/her to put @combinatorial_map in front of the method in > question. In other words, there should be no need to change the interface > for those who contribute combinatorial maps. What should change is how this > contribution is processed. It should not be the case that, as a result, > the overhead of calling a method increases! > > What I (an Nathann?) am trying to convince y'all: @combinatorial_map > should not wrap a method into some class instance that serves as a proxy > to the method and holds additional information purely locally. Instead, > @combinatorial_map should communicate with a (local) database before > returning the method *unwrapped*. And then, there should additionally > be tools to use the local database together with a global one. > > > > What I > > like about a local system (preferably accompanying the code of the > > very method) is that it makes it easy for the person having > > information about a specific map to provide that information. > > To give you a drastic picture: Imagine you work for a company and want > to keep track who is your customer. You suggest to attach a little tag > to each customer, stating that (s)he is "happy customer of FooBar ltd.". It > will then be very easy to test if a given person is your customer: Just > look for the tag. And when you want to have a list of your customers in > a given town: Just do an exhaustive search in that twon and check each > person's tag! > > But I somehow feel that having a database keeping track of your > customers would be better. And I do believe that tagging a method as > "combinatorial map" locally is the same as tagging your customers > locally. So, the picture applies. > > > Of course, that information must be organized to be searchable > > properly. But I don't see a problem there beside conventional namings. > > Hang on. Do you suggest to implicitly create a database that relies on > naming schemes?? > > I think one can not deny: What y'all do with the @combinatorial_map *is* > in fact creating a database---at least implicitly---, whether you want > it or not. But explicitly is better than implicitly, and one should not > re-invent the wheel. So... > > Best regards, > Simon > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
Hi Paul, On 2014-05-28, Paul-Olivier Dehaye wrote: > Christian's point is key. The absolute hardest problem to solve is where to > anchor semantic information so that others can contribute to it easily, > ... > Right now, by lack of a better place, it is put in sage. I think you miss the point of what Nathann and I try to say. I think Nathann agrees that it is a reasonable idea to have a @combinatorial_map decorator in front of a method (I do agree), provided that it gives useful information to some people (this is the case now), and provided that it does not have a negative impact for people who don't use this information---and currently it *does* have a negative impact, because of a slow-down in potentially time-critical methods. Last attempt before leaving office: - Currently we have a lose-lose situation: When people put @combinatorial_map, then it has a negative impact to some other people (the slow-down), and it is difficult to use the added information for those who want to do proper queries. - We should better have a win-win situation: When people put @combinatorial_map, then it should not change the method (to not slow-down stuff), and the added information should be accessible to queries in a reasonable way. Cheers, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
Hi Christian, On 2014-05-28, Christian Stump wrote: > But how am I then convincing > someone knowing that information to add that information there? Ask him/her to put @combinatorial_map in front of the method in question. In other words, there should be no need to change the interface for those who contribute combinatorial maps. What should change is how this contribution is processed. It should not be the case that, as a result, the overhead of calling a method increases! What I (an Nathann?) am trying to convince y'all: @combinatorial_map should not wrap a method into some class instance that serves as a proxy to the method and holds additional information purely locally. Instead, @combinatorial_map should communicate with a (local) database before returning the method *unwrapped*. And then, there should additionally be tools to use the local database together with a global one. > What I > like about a local system (preferably accompanying the code of the > very method) is that it makes it easy for the person having > information about a specific map to provide that information. To give you a drastic picture: Imagine you work for a company and want to keep track who is your customer. You suggest to attach a little tag to each customer, stating that (s)he is "happy customer of FooBar ltd.". It will then be very easy to test if a given person is your customer: Just look for the tag. And when you want to have a list of your customers in a given town: Just do an exhaustive search in that twon and check each person's tag! But I somehow feel that having a database keeping track of your customers would be better. And I do believe that tagging a method as "combinatorial map" locally is the same as tagging your customers locally. So, the picture applies. > Of course, that information must be organized to be searchable > properly. But I don't see a problem there beside conventional namings. Hang on. Do you suggest to implicitly create a database that relies on naming schemes?? I think one can not deny: What y'all do with the @combinatorial_map *is* in fact creating a database---at least implicitly---, whether you want it or not. But explicitly is better than implicitly, and one should not re-invent the wheel. So... Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Christian's point is key. The absolute hardest problem to solve is where to anchor semantic information so that others can contribute to it easily, because his project requires lots of microcontributions (cf. Nielsen's Reinventing Discovery) Right now, by lack of a better place, it is put in sage. According to me, this is a sensible short term solution, step 1 if you want. Step 2 is that the LMFDB starts to do the same thing putting semantic information on empty classes and methods. Step 3 is that we find a better way, armed with two use cases. I don't think we are ready to go to step 3 yet. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 4:37 PM, Christian Stump wrote: > > Ceterum censeo: Please do not put too much semantic into an attribute of > > the map. It will be a burden for the map, will cost memory, and will be > > difficult to search. > > I would personally really like to get semantic information about maps > implemented in Sage. This starts with automated concatenating maps, > and does not even end with information about a map in the Journal of > Applied Nonsense. I am sure you have reasons to vote for a centralized > system where to store such information. But how am I then convincing > someone knowing that information to add that information there? What I > like about a local system (preferably accompanying the code of the > very method) is that it makes it easy for the person having > information about a specific map to provide that information. > > Of course, that information must be organized to be searchable > properly. But I don't see a problem there beside conventional namings. > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> Ceterum censeo: Please do not put too much semantic into an attribute of > the map. It will be a burden for the map, will cost memory, and will be > difficult to search. I would personally really like to get semantic information about maps implemented in Sage. This starts with automated concatenating maps, and does not even end with information about a map in the Journal of Applied Nonsense. I am sure you have reasons to vote for a centralized system where to store such information. But how am I then convincing someone knowing that information to add that information there? What I like about a local system (preferably accompanying the code of the very method) is that it makes it easy for the person having information about a specific map to provide that information. Of course, that information must be organized to be searchable properly. But I don't see a problem there beside conventional namings. -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
Hi Christian, On 2014-05-28, Christian Stump wrote: > --> Can I turn any method in Sage which mimics a mathematical function > into a map in the above sense? To put it differently: Is it right that > there are always (or almost always) parents available to use as domain > and codomain? Any function can be made a morphism by wrapping it in SetMorphism. However, the question is whether you can easily construct domain and codomain. Domain and codomain must be instances of CategoryObject, if I recall correctly. If we talk about maps of a specific subset of X to a specific subset of Y (e.g., a map from prime numbers to non-negative integers), then I guess facade parents can be used. > --> How do you think "more semantic" should be implemented? As a dict > with some conventions for keys and values? Ceterum censeo: Please do not put too much semantic into an attribute of the map. It will be a burden for the map, will cost memory, and will be difficult to search. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi!
On Wed, May 28, 2014 at 11:54:22AM +0200, Vincent Delecroix wrote:
> Hi Christian,
>
> 2014-05-28 11:32 UTC+02:00, Christian Stump :
> >> It seems that actually nobody read my initial post on that thread... so
> >> let me repeat
> >
> > I did -- but didn't really have any qualified contribution...
> >
> >> But the semantic has to be implemented at the level of maps not at the
> >> level of methods.
> >
> > could you explain what you mean there (maybe using your example of the
> > number of descents of a permutation).
>
> A method ( = a Python function) is not a Sage Map ( = a Python object
> that model a mathematical function). I would like first to convert the
> method into a map
> {{{
> from sage.categories.map import Map
> class NumberOfDescents(Map):
> def __init__(self):
> Map.__init__(Permutations(), NonNegativeIntegers())
>
> def _call_(self, p):
> return Integer(p.number_of_descents())
> }}}
> The above example is already non-trivial since it specifies a domain
> and a codomain (which is different from the parent of the image of an
> element):
> {{{
> sage: nod = NumberOfDescents()
> sage: p = Permutation([3,2,1])
> sage: nod(p)
> 3
> sage: nod(p).parent() is NN
> False
> }}}
> The second step would be to think how to add semantic to the map. Part
> of is already managed by the axioms/categories (for example a Morphism
> between GradedSets preserve the grading). But there is nothing for
> injectivity/surjectivity or more subtle properties.
For whatever it's worth: in MuPAD, it was possible to add type
annotations on a method; typically to specify the domain and codomain:
abs := proc(x: Dom::Integer): Dom::Integer
begin
return(x)
end
We were using this extensively for:
- Dynamic type checking in debug mode
- Retrieving the domain or codomain, typically when constructing new
functions from existing ones (e.g. in module_morphism)
- ...
Python 3 will allow to add similar annotations. In the mean time we
could possibly stuff such annotations to glorify methods:
sage: def f(x): return abs(x)
sage: f.domain=ConstantFunction(ZZ)
sage: f.codomain=ConstantFunction(NN)
sage: f(-3)
3
sage: f.domain()
Integer Ring
sage: f.codomain()
Non negative integer semiring
Anyway, just food for thoughts; it's not like there is a clear plan in
this direction.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
Hi Vincent,
On 2014-05-28, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> A method ( = a Python function) is not a Sage Map ( = a Python object
> that model a mathematical function). I would like first to convert the
> method into a map
Which is trivially possible, see sage.categories.morphism.SetMorphism:
It accepts any callable as input. Hence, a method should be acceptable.
> {{{
> from sage.categories.map import Map
> class NumberOfDescents(Map):
> def __init__(self):
> Map.__init__(Permutations(), NonNegativeIntegers())
>
> def _call_(self, p):
> return Integer(p.number_of_descents())
> }}}
> The above example is already non-trivial since it specifies a domain
> and a codomain (which is different from the parent of the image of an
> element):
OK, here we have facade sets at work.
> The second step would be to think how to add semantic to the map.
> ...
> Part
> of is already managed by the axioms/categories (for example a Morphism
> between GradedSets preserve the grading). But there is nothing for
> injectivity/surjectivity or more subtle properties.
I would oppose against adding *arbitrary* flags as attributes to the map.
Perhaps the guideline should be: What facts does a morphism need to know
in order to work? What facts are related with it being a morphism?
E.g., it should know domain and codomain, and it should know
what category it belongs to. I think it makes sense to let a morphism
know whether it is injective or surjective. However, additional
information that is certainly interesting to researchers (e.g.: "Was first
defined by John Doe in his seminal paper in Journal of Applied
Irrelevance") clearly should not be stored as an attribute of a morphism.
So, I guess you should be more specific: What properties are you talking
about?
> It would make more sense to register actual maps as above.
Register *where* and *how*? And what do you mean by "register actual maps"?
To answer "where" and "how", one should first know: How do you intend to use
the registered data?
For example, if you want to ask questions such as "what mathematically
meaningful bijections have been constructed between enumerated sets X
and Y?", then the property of being "mathematically meaningful" should
not be registered in the map---simply because it would be difficult to
search in distributed data. Hence, if you want to register a map as being
"mathematically meaningful bijection", then it should be in a central
place, aka database, IMHO.
Concerning "registering actual maps":
What you would register in this central location is not necessarily a
map that you need to create before registering it. The decorator just
needs to tell the database: "Take object X and object Y, and wrap
the method X.john_doe_morphism into a SetMorphism; the result will be an
isomorphism of X and Y in the category Blahs()".
As a result, the database will know how to *explicitly* construct an
actual morphism---but it would only be explicitly constructed upon
request.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> The second step would be to think how to add semantic to the map. Part > of is already managed by the axioms/categories (for example a Morphism > between GradedSets preserve the grading). But there is nothing for > injectivity/surjectivity or more subtle properties. Thanks for the clarification! I have a few more questions there: --> Can I turn any method in Sage which mimics a mathematical function into a map in the above sense? To put it differently: Is it right that there are always (or almost always) parents available to use as domain and codomain? --> How do you think "more semantic" should be implemented? As a dict with some conventions for keys and values? --> What if I want to give properties that depend on input parameter like the length of the permutation? Say I look at the map from Permutations(n) to itself given by composition with the long cycle (1..n), and now want to add the semantic information that it has order n? --> Is there a way to implement your ideas such that the lines of code I need to touch in order to turn a method into a map is right where the method is implemented? Thanks, Christian -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Vincent, I did read your email, which is very good. Thank you for posting.
Unfortunately it is too focused for my taste. I would like to solve the
generic problem of how to put in semantic information in sage first. Many
might say let's solve one problem first, but in my mind it is already three
times that this problem is appearing:
- LMFDB
- findstat
- category framework
That's why people who were at Edinburgh were invited.
I am looking for a generic solution, and to help with this I have started
writing a document that is read only here:
https://etherpad.mozilla.org/ep/pad/view/ro.Gzkl7YR-2gG/latest
I am not writing this document at this exact moment, because I have a
pressing deadline until Sunday. I am willing to devote much more time for
this then. This is not an empty comment, in some ways my pressing deadline
of Sunday is because I am already working on this. My timing is slightly
affected, because in the back of my head I knew I just had to wait for the
next flare up of this discussion on the list to get another discussion
started, but this time backed up with concrete elements.
Anyone who would like to help me add constructive material to the document
is welcome to do so, just ask me for the link.
@Christian: a generic, better, query engine might be build outside of
findstat if the findstat group is too focused on their particular use case.
Believe me, findstat is as far as I can tell baby case compared to LMFDB.
But it has the merits of trying a more viable approach in my mind.
I certainly don't want to develop anything without explicitly telling
findstat about it.
Paul
Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye
On Wed, May 28, 2014 at 11:54 AM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:
> Hi Christian,
>
> 2014-05-28 11:32 UTC+02:00, Christian Stump :
> >> It seems that actually nobody read my initial post on that thread... so
> >> let me repeat
> >
> > I did -- but didn't really have any qualified contribution...
> >
> >> But the semantic has to be implemented at the level of maps not at the
> >> level of methods.
> >
> > could you explain what you mean there (maybe using your example of the
> > number of descents of a permutation).
>
> A method ( = a Python function) is not a Sage Map ( = a Python object
> that model a mathematical function). I would like first to convert the
> method into a map
> {{{
> from sage.categories.map import Map
> class NumberOfDescents(Map):
> def __init__(self):
> Map.__init__(Permutations(), NonNegativeIntegers())
>
> def _call_(self, p):
> return Integer(p.number_of_descents())
> }}}
> The above example is already non-trivial since it specifies a domain
> and a codomain (which is different from the parent of the image of an
> element):
> {{{
> sage: nod = NumberOfDescents()
> sage: p = Permutation([3,2,1])
> sage: nod(p)
> 3
> sage: nod(p).parent() is NN
> False
> }}}
> The second step would be to think how to add semantic to the map. Part
> of is already managed by the axioms/categories (for example a Morphism
> between GradedSets preserve the grading). But there is nothing for
> injectivity/surjectivity or more subtle properties.
>
> It would make more sense to register actual maps as above.
>
> Vincent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-combinat-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-combinat-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-combinat-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-combinat-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi Christian,
2014-05-28 11:32 UTC+02:00, Christian Stump :
>> It seems that actually nobody read my initial post on that thread... so
>> let me repeat
>
> I did -- but didn't really have any qualified contribution...
>
>> But the semantic has to be implemented at the level of maps not at the
>> level of methods.
>
> could you explain what you mean there (maybe using your example of the
> number of descents of a permutation).
A method ( = a Python function) is not a Sage Map ( = a Python object
that model a mathematical function). I would like first to convert the
method into a map
{{{
from sage.categories.map import Map
class NumberOfDescents(Map):
def __init__(self):
Map.__init__(Permutations(), NonNegativeIntegers())
def _call_(self, p):
return Integer(p.number_of_descents())
}}}
The above example is already non-trivial since it specifies a domain
and a codomain (which is different from the parent of the image of an
element):
{{{
sage: nod = NumberOfDescents()
sage: p = Permutation([3,2,1])
sage: nod(p)
3
sage: nod(p).parent() is NN
False
}}}
The second step would be to think how to add semantic to the map. Part
of is already managed by the axioms/categories (for example a Morphism
between GradedSets preserve the grading). But there is nothing for
injectivity/surjectivity or more subtle properties.
It would make more sense to register actual maps as above.
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> It seems that actually nobody read my initial post on that thread... so let > me repeat I did -- but didn't really have any qualified contribution... > But the semantic has to be implemented at the level of maps not at the level > of methods. could you explain what you mean there (maybe using your example of the number of descents of a permutation). -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
It seems that actually nobody read my initial post on that thread...
so let me repeat
There are two disjoint tasks:
- add semantic to Map and Morphism (Sage)
- gather the list of meaningful maps (Sage/FindStat)
First of all, most of us agree that we need more semantic at the level
of maps. Note that Morphism is already a way of providing semantics as
it tells that the map preserves some structure. It will not hurt me
too much to have aliases satistics and combinatorial_map for whatever
they are. But the semantic has to be implemented at the level of maps
not at the level of methods.
As Vivianne agreed: combinatoral_map is currently an empty class whose
purpose is to tag some methods as being of the good kind. The only
semantic added is "that method is actually a map".
Secondly, there is the thing at what FindStat is good: gathering the
set of meaningful maps from Parent A to Parent B. I will not develop
on the technical part underlying this question as it was already
discussed. But it would be good to have the infrastructure and some of
the information in Sage. In other words, a function which register
maps
{{{
sage: my_map = build_map_from_method(domain, range, category=X,
method_name='toto', injective=True)
sage: register_map(my_map)
}}}
In some places, a decorator might be the way to proceed.
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> Just to make this statement more precise: it will not be possible within the > next two years if Mmarco relies on your availability for this (there is no > blame in that statement, it's just a clarification that others might be > willing to work on this problem). It is not a problem -- it's the way we set up our project! Its main features are designed for users who do not want to do any coding or even seeing a terminal environment. And that's good about it and one of the reasons why people like it! I recently talked about the project with Michelle Wachs -- she was actually asking about it! -- and she seemed to be really impressed. I think that didn't just come from the bare functionality, but from the easy possibility for her to interact with it. Anyone who is interested in working on more sophisticated features to be done from within Sage are very welcome to talk to me and/or to Chris Berg (though he might be a little less responsive these days) about it to see how we can approach it. But I would not like if I find out in 18 months from now that someone implemented a much stronger query machine (which is certainly possible) based on our ideas, but without collaborating with us! Cheers, Christian -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> > --> It will not be possible (say within the next two years, except the > unlikely event that I will a lottery without participating, and then > spend some money to hire a professional programmer) to only query the > statistics data, and do the computations within your own Sage. Just to make this statement more precise: it will not be possible within the next two years if Mmarco relies on your availability for this (there is no blame in that statement, it's just a clarification that others might be willing to work on this problem). Paul -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Hi Mmarco, This is a functionality many of us would want too. The question that is unclear is how to implement it in the best way. What Nathann refers to as "some kind of protocol to transfer the combinatorial objects" is a very hard problem. Fortunately, many people are starting to realise that this is a desired functionality and constructively try to find solutions. Depending on your background, you might be able to directly help, for instance by annotating some of the functions in the sage code (a very easy thing to do, for which you need only a web browser. This is a tiny step above editing documentation). People are actively working on this problem Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 10:01 AM, Nathann Cohen wrote: > > Would it be possible to include the findstat functionality in sage? > > It is possible to write the code, and desirable. As the Sage is > open-source, you are also welcome to give it a try if you need the feature. > Sage already queries the OEIS, though for FindStat you will probably have > to design some kind of protocol to transfer the combinatorial objects with > the website's owners. I am told that you can contact them at > i...@findstat.org. > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> Would it be possible to include the findstat functionality in sage? That is, > i have a bunch of pairs (permutation, number), then call the function > findtsta on them, and get a list of possible ways that the numbers can me > computed from the permutations. All inside sage, without need to go to the > findstat webpage. I really appreciate that so many people appear to be interested in the FindStat functionality, being it from within Sage or from the FindStat webpage! --> It is almost sure that it will *never* be possible to use FindStat without a web connection --> Nevertheless, it is on our ToDo list (which is, as for basically everyone, very packed -- I don't promise anything for a given time in the future) to provide a text based query to the database to obtain machine readable results that can be parsed into Sage. That should go similarly to the Sage functionality for the OEIS. BUT please see that querying FindStat is *much more complicated* than the simple query for the OEIS: (A) the data structure is more complicated, (B) the "following maps" is much more complicated. --> It will not be possible (say within the next two years, except the unlikely event that I will a lottery without participating, and then spend some money to hire a professional programmer) to only query the statistics data, and do the computations within your own Sage. That's because there is (A) in additional layer of code on top of Sage that makes that possible and (B) this layer is extra thick because we also have stuff there that could be part of Sage but is not because there is a *partial unwelcoming attitute* that prefers to give a "that's not good for Sage" over "include non-perfect code, even if it would have a strictly positive influence on the Sage user community" in such instances. Cheers, Christian -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] combinatorial statistics
Since you ask, here is a thread where you have insulted me repeatedly: http://trac.sagemath.org/ticket/16403 Others might think I have asked for it, but that's a different question, and we can have that debate too if you want. But if we are going to have that debate, I would ask that you first send me all links you think are relevant, and that you accept that I send you all links that I find relevant (which might be research papers on the topic of lone individuals' net negative contributions to open source software development, despite producing lots of code. For instance that would include background reading/video watching relevant to the diversity thread). I would also ask that we both spend the time that is needed to actually read through those links and then set a date for the debate to start, and a place that the debate is held. This way everyone can make sure to prepare their own popcorn and know of where to watch. Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 9:57 AM, Nathann Cohen wrote: > Yo ! > > > > I find it quite difficult now to follow this thread, I see the answer to > some emails that are not even in the thread... > > This is because it was sent to both sage-devel and sage-combinat. After a > while somebody anwers to only one group and mess follows. > > > > Anyway, I just want to answer to this specific sentence of Nathan: "This > is only technical issues, nothing more. But I hate that it takes one year > to see it fixed." > > > > Well, Nathan, you just have to live with it! See, we're all working on a > global project depending on lots of people, we all have to wait. The fact > that you hate / love something has no impact on my time line whatsoever. > > This is very very easy on you Don't you feel any responsibility at all > for what you put into Sage ? We had a conversation one year ago about ways > to fix that, one of which seems to suit you as you said on sage-devel just > yesterday. And when several persons tell you that your design has a fault, > and a way to solve it, you answer them with a "Just live with it ! The fact > that you love/hate it has no impact on my time line whatsoever" ? > > > > And you should understand that you won't make things faster by a) > insulting people (as you did last year) and b) giving orders (as you just > did in this very thread). > > I assume that what you call giving orders is this : > > > "Our discussion about this is almost 1 year old. If you do not know how to > clean this code this month, please remove it." > > You will have to provide the link yourself if you want to claim that I > insult people. I don't claim that it never happens, but I am very > interested in the context. > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: redesign combinatorial statistics
> Would it be possible to include the findstat functionality in sage? It is possible to write the code, and desirable. As the Sage is open-source, you are also welcome to give it a try if you need the feature. Sage already queries the OEIS, though for FindStat you will probably have to design some kind of protocol to transfer the combinatorial objects with the website's owners. I am told that you can contact them at i...@findstat.org. Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] combinatorial statistics
Yo ! > I find it quite difficult now to follow this thread, I see the answer to some emails that are not even in the thread... This is because it was sent to both sage-devel and sage-combinat. After a while somebody anwers to only one group and mess follows. > Anyway, I just want to answer to this specific sentence of Nathan: "This is only technical issues, nothing more. But I hate that it takes one year to see it fixed." > > Well, Nathan, you just have to live with it! See, we're all working on a global project depending on lots of people, we all have to wait. The fact that you hate / love something has no impact on my time line whatsoever. This is very very easy on you Don't you feel any responsibility at all for what you put into Sage ? We had a conversation one year ago about ways to fix that, one of which seems to suit you as you said on sage-devel just yesterday. And when several persons tell you that your design has a fault, and a way to solve it, you answer them with a "Just live with it ! The fact that you love/hate it has no impact on my time line whatsoever" ? > And you should understand that you won't make things faster by a) insulting people (as you did last year) and b) giving orders (as you just did in this very thread). I assume that what you call giving orders is this : "Our discussion about this is almost 1 year old. If you do not know how to clean this code this month, please remove it." You will have to provide the link yourself if you want to claim that I insult people. I don't claim that it never happens, but I am very interested in the context. Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: redesign combinatorial statistics
A slightly unrelated problem: Would it be possible to include the findstat functionality in sage? That is, i have a bunch of pairs (permutation, number), then call the function findtsta on them, and get a list of possible ways that the numbers can me computed from the permutations. All inside sage, without need to go to the findstat webpage. -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
