Re: [sage-combinat-devel] Re: Code duplication
Would it make sense to 1. move sage.misc.binary_tree to sage.data_structures? After all, the implementation is about a general data structure that is independent of Sage's parents and elements. +1 to that. This being said, do you know if it is used anywhere? That code has been written in 2007 and has not seen any serious improvement since. As it is quite lacking on the documentation side, perhaps we could just throw it away if nothing relies on it. I cannot answer for your second question on the combinat code, but I have do not doubt that somebody will feel compelled to. 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: Code duplication
Part of my suggestion is to use it more widely (e.g., in sage.combinat), since it seems to be more promising in the speed department than what is currently used. Oh sorry, I missed that. Well, in that case it deserves to be saved ;-) 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: Test digraph for cycles containing a vertex?
This is a little silly, Right :-P I thought that it did not work with iterators only, and I did not even try ^^; 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: Test digraph for cycles containing a vertex?
I would imagine this would be relatively efficient: Do not use that. If you want to figure out if there is a path from u to v, compute the distance (or a shortest path) between the two. 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: Test digraph for cycles containing a vertex?
Probably that won't be needed. At some point I need to know if a vertex is part of an oriented cycle. That's all. I need to know it only once. Okay. Then try that: sage: any(v == x for x in d.breadth_first_search(d.neighbors_out(v))) Algorithmically it is optimal, but it is written at higher level than the strongly connected components routines (and may be slower as a result). 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: Test digraph for cycles containing a vertex?
Hello, How should one test whether v is contained in a cycle (including loops)? If you want it to be fast, the best is to re-write a modified breadh-first-search starting from v. If you ever find an edge going back to v, then it is contained in a circuit. 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: Test digraph for cycles containing a vertex?
If you want it to be fast, the best is to re-write a modified breadh-first-search starting from v. If you ever find an edge going back to v, then it is contained in a circuit. P.S.: graphs are not part of combinat, despite what they advertise from time to time [1]. Nathann [1] file:///home/ncohen/main2014.pdf -- 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: Test digraph for cycles containing a vertex?
Thank you! I thought that finding the *shortest* path would be more difficult than finding *some* path. It is true is you take the edge's weighting into account, but you get this more or less for free otherwise. But I guess the way paths are constructed is by increasing length... Indeed. And a BFS is cheap. Do you need it to be very very fast? If it is for your path algebras, then it can probably be written very low at backend level. 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: [sage-devel] Re: List of methods at beginning of files
For graphs, the list is also long and is separated by theme (everything done by hand) : I also like those a lot: http://doc.sagemath.org/html/en/reference/graphs/sage/graphs/graph_generators.html http://doc.sagemath.org/html/en/reference/combinat/sage/combinat/designs/database.html It would be cool to have an automatic lexicographic listing, however. Thematic sorting is cool and everything but it takes a lot of time, and it will never happen on all files at once. 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: remove combinat/mupad from sagemath website
Yo ! Me neither. The current situation isn't ideal, but just removing one page and merging everything else doesn't help. That's not what the pull request does. 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: remove combinat/mupad from sagemath website
Well, that's a little bit insulting. I'm that nobody and just for the record, I did work quite a lot of work last august. Well no, nobody means nobody. You are the first one who told me about these scripts that nobody understands. You could also ask me -- but despite that, I do not really understand why you want to clean up the scripts. They do not cause any harm if they are there, right? It depends who you are. If you never touch the website and have it store what you needs, then of course you are not bothered. If you know the website better than anybody else (=you) then you must know your way around, and you are not bothered. But if you do not know (like me) where are the three different versions of the same copy/pasted text in the website, then you prefer to have only one of them and pointers toward it. And if you look for something in particular and have 3 undocumented scripts which seem to do the job, only one of which is active, then you begin to seriously lose your time trying to figure it out. So yeah, I prefer when I only see the active files in a directory. Mupad-combinat's page is not a huge bother, it just has nothing to do on Sage's website. 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: remove combinat/mupad from sagemath website
I'd appreciate if you would keep that page where it is. I don't doubt it. But perhaps you should stop considering Sage's website as a convenient way to store your pages. It strikes me at the moment that I am the one trying to rearrange sage-combinat's and mupad-combinat's bibliography, while your role is to tell me how you want it arranged. The time that you save for yourself is the time that others (e.g. me) spend managing what you don't want to think about. Sage's website, in particular, is mostly a very very long collection of oldies which nobody understands. The remnants of remnants of remnants of old versions of something. And on top of that you have guys explaining how we should keep the data of another software, dead for 7 years. 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: remove combinat/mupad from sagemath website
Sage-Combinat is part of Sage. Sage-Combinat's website is a page on the Sage wiki. The Sage-Combinat's NSF grant benefited Sage at large. I don't see the point of suddenly having to duplicate the infrastructure. Yeah. But Mupad-combinat is none of that, yet you expect us to host it. Also, I wouldn't mind your hosting it there if you were the one working on the maintenance. But others will do it for you, won't they? 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: remove combinat/mupad from sagemath website
Isn't it possible to just remove the link to the mupad page from the menu without removing the page? Then the page would only be accessible from the combinat page, which makes sense. And the link is the following: https://github.com/sagemath/website/pull/46 Honestly, I cannot see the cost of hosting a html page on a related former project... If you want to figure this out, an easy way for you would be to checkout the 'website' git repository and look at what is inside, how it is arranged. As I said before, there are many things in there for which *nobody* knows what exactly they are about. Undocumented scripts, things which are never called by anything else, different workflows on top of each other. I am trying to clean this. When you want to figure out what each of these things is doing here, the best you can do is remove what you do not need. When you notice that there are things in there that are not even related to Sage because people thought that it was more convenient for them to not deal with it by themselves, you think of giving up. But of course they are not the ones doing the cleaning. 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: remove combinat/mupad from sagemath website
- The MuPAD-Combinat citation list is unlikely to evolve much more. I agree that there is no compelling reason to have a link sagemath.org - Library - Citations MuPAD; so if you want to remove that link, that's fine with me. On the other hand, there probably isn't much cost nor confusion involved in keeping the page: http://www.sagemath.org/library-publications-mupad.html just to save the time on relocating it elsewhere. Also I would find natural to have a link from the Sage-Combinat list to that list, with a word of explanation. So you agree with my proposal. It will be done by tomorrow. 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: remove combinat/mupad from sagemath website
Nathan proposes to remove some older publication links from the SageMath website. More precisely, I propose to: - Remove the Publications Mupad page. This software is not Sage, is not part of Sage either, and has not been maintained for the past 7 years according to its website. This page of publications is also unmaintained, e.g. there is a 'preprint' from 1999. - Merge Publications Sage and Publications Combinat into one page: (by 'merging' I mean having them all on one page, first the 'pure-sage' publications then the 'combinat' publications in another group) For a while, there would be a redirection from the current sage-combinat publication page to the right place in the merged 'all-publications' page The reason for these changes is that our website is currently very messy on many points. There is a lot of duplicated contents, many broken links that should be removed, and many places where users would be lost easily (e.g. the three 'report a bug' links, right next to each other). I would like to simplify its layout. And to this end, I believe that 'Library - Publications' is a better interface than three different links. 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: remove combinat/mupad from sagemath website
With the amendments I mention above, I am ok with it. I noted two: 1) A link from the new (merged) page to the Mupad-combinat page 2) You will relocate the mupad page to mupad-combinat's home page, and send me an email when it is done so that we can remove it from Sage's server and update the links. 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: remove combinat/mupad from sagemath website
No. Please reread. Same result. Care to make yourself clearer? 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] Categories and the top level
Hello, As for putting them in a catalog: I don't have a strong opinion. As long as we I can put in my .sagerc: sage: from categories import * I am all good with it if someone volunteers. This very syntax was something that the code guys wanted to implement recently. Volker defended that it was a bad idea: http://trac.sagemath.org/ticket/18107#comment:24 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: Order of Partitions()
Hello, I think that Partitions should be output in either lex (or possibly reverse lex) since this order is compatible with dominance order. I only want to bring to your attention that deciding in which order the partitions should be returned is not free in terms of computational time. The current implementation returns them in lex order, but returns *many* wrong answers too (see #17548). In order to fix that, Jeroen is re-implementing this feature through a routine that enumerates the integer points of a polytope (see #17920), probably without any control over the order in which they are returned. Thus, in order for Partition/Composition to return them in a specific order we must list them *all* before returning the first of them. This can really mean hours (or no results at all) instead of seconds on big instances. 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: obtaning meet semi-lattices with n elements
Hello, As Sage is open-source you can usually answer such questions by reading the code, or the function's documentation. In this specific case, however, I do not know if we actually have this feature in Sage: do you *know* how to enumerate meet-semilattices in Sage? If so please share the commands, and we will probably find in the doc a description of the algorithm it implements. Nathann On Wednesday, March 11, 2015 at 11:44:07 AM UTC+1, Ercan Altınışık wrote: Dear all, I am studying the divisibility problem of meet and join matrices which deals with the structure of finite meet semi-lattices. I know that Sage generates a list of Hasse diagrams meet semi-lattices with n-elements. I wonder how to construct meet semi-lattices with n elements. I have Stanley's texts (EC1 and EC2) and also the following paper of Heitzig and Reinhold. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.24.2420rep=rep1type=pdf Is the method used in Sage to obtain meet semi-lattices based on checking all possible meets in the posets with n elements? Or are there any other method to construct them? Especially a recursive method? best regards, Ercan Altinisik -- 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: [sage-devel] bug report: interval graph recognition
Fixed. Thanks Dima for the review ! http://trac.sagemath.org/ticket/17787 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: [sage-devel] bug report: interval graph recognition
This is a bug report from a Sage user... He also sent me an email. The bug report is correct, I'll see what happens. 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: [sage-devel] Re: Sage grant
Hello ! Regarding this request, William has a question which interactive visualization objects would be most useful for people with combinatorial inclination. Certainly graphs, trees, but I guess also 3- or multi-dimensional objects such as plane partitions and polytopes ... Anything else? Can I suggest hypergraphs ? :-P sage: view(designs.steiner_triple_system(9)) # quite messy, isn't it ? I believe that when it comes to visualization we are more quickly limited by the means, not by the objects themselves. There is only so much that you can do with matplotlib. I gave d3.js a try at some point and I believe it can lead us to better graphics [1]. Right now the interface is a bit hackish but if it becomes used more widely than it is now we will probably end up writing something clean and reliable for all plots. sage: graphs.RandomTree(30).show(method=js) Nathann [1] https://github.com/mbostock/d3/wiki/Gallery -- 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: Sage grant
Yo ! Does Math directorate pay for programmers to write open-source versions of commercial software? flame Of course not. It is just that when commercial softwares fail to do the job, we have to do it in their stead. And we cannot seriously expect them to implement what we need for our research, very often that code is only interesting/useful to researchers. /flame Or are these topics designating novel algorithms and data structures? Well. For instance you will find this feature quite useless to non-researchers: sage: print designs.orthogonal_arrays.explain_construction(10,814) Construction 3.4 with n=17,m=47,r=6,s=9 from: Julian R. Abel, Nicholas Cavenagh Concerning eight mutually orthogonal latin squares, Vol. 15, n.3, pp. 255-261, Journal of Combinatorial Designs, 2007 sage: print designs.orthogonal_arrays.explain_construction(22,792) Lemma 4.1 with n=25,m=28 from: Charles J.Colbourn, Jeffrey H. Dinitz, Mieczyslaw Wojtas, Thwarts in transversal designs, Designs, Codes and Cryptography 5, no. 3 (1995): 189-197. It tells you in which paper was proved the existence of an orthogonal array OA(10,814) and OA(22,792). If not for Sage, it is just impossible to find out this kind of information (*). That's not really computer science, that's more archeology than mathematics, but it can be useful to (some) mathematicians. Nathann (*) It is not just a database. We implement different recursive constructions from different papers, Sage computes all possible combinations of them and find out which leads to the result. I dare you to do it with a paper and pen :-P -- 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: [sage-devel] Re: Sage grant
Yo ! Hey, just to make it clear: I am not supporting their grant request industry. I could not care less, and if anything I just hate to see that people use Sage (which includes some of my own work) to request solid money for themselves. I just did not want to let you have the last word when all you do here is say that mathematica is better. Nothing smart involved. About the actual request: I believe that it contains the usuall bull***, and includes as many fancy words as possible while not claiming that anything too specific will happen, so that you can do whatever you want with the money. 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: sum(Composition([1,2,3])) # broken
Has a decision been reached ? #10963 is in Sage now, and the bug is still here. 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] About nested functions not showing up in the doc
Hello everybody ! Vincent implements in #16464 a method for Rings, which is located in Rings.Finite.ParentMethods.cyclotomic_cosets [1]. Trouble is, this function does not appear in the html documentation and I remember Nicolas having said something about that, like Sphinx does not print too deeply nested functions. Given that you are the absolute kings of over-nesting stuff, it means that a lot of Sage's functions do not appear in the doc. What have you tried on this front ? Have you, for instance, written something to the Sphinx guys ? Do you have any plans to make those functions appear ? You can of course get the documentation from inside of Sage, but not through google, and that's a pity. Have fun ! Nathann [1] Thanks god for which-function-mode in Emacs. -- 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] About nested functions not showing up in the doc
That's #9107, it just takes pushing through some technical latex issue according to plan stated on sage-devel ... I hope to have the time for this at some point, unless someone beats me to it! A 4 years old ticket whose last comment is 10 months old ? Cool to see that this is being solved. 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: About nested functions not showing up in the doc
If I recall correctly, I am (one of the) author(s). However, the ticket ran against a limitation of LaTeX that made it impossible to create the pdf reference manual with the nested classes, and I have not the faintest idea how to work around/shift these LaTeX limiations. So, if you happen to be a LaTeX expert, please step forward. I am not. Do you think that we need a pdf version of the manual ? I have no idea of how it could be more useful than the html documentation. We can't just give up documenting all the functions that are nested in the category/ folder just because LaTeX is the worst piece of code ever. 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
Yoo !! Nathann, Christian, Viviane, ... do you mind briefly stating on the ticket whether this sounds like a reasonable step forward? Well... I don't have much to add there I think... Besides, for political reasons, you will understand that I cannot review this ticket :-P For me what you do is fine. I agree with Vincent that you are actually wiping the feature out while leaving a way to fill a database. And this database will only be built by the find_stat guys. But to me it is not a problem : they can use the information they like to build their database (because they already have something running) and we have all the time in the world to figure out what we want to do with this information on our side. Plus, of course, the decorator will not change anything to the functions, which was the point :-P 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
BUT: this would result in code in Sage that is not useful purely within Sage. And there are people, loud people, that say there should not be such code in Sage. I can hear your frustration ... In similar situations, it helped me to keep in mind that loud people are not always representative. Of course the difficulty is to fetch the opinion from the others. Ahahahahahahah. Well, only including in Sage code that is useful to a Sage user or other developpers does not seem that far-fetched. I still do not see what the problem is with that. Err Well, assuming the obvious : that I am the loud people you mention. 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
I might be too, I am not quite sure! If so, I would be ashamed to steal the spotlights. The place is yours. 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-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics
Yo ! 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. which is a very open minded attitude and a jest, as I am sure you understood. I was answering a post which was partly about what Nathann thinks, and I did not feel that I had anything important to contribute. Nathann, I understand you don't know now what you think and respect that. I love knowing that I am respected for such effortless achievements. But did you _really_ use to think that the Graph class was yours, in the sense that you had veto rights on it? I am assuming that's the class you are referring to. I have veto rights on anything that anybody does even when I am not looking. Fortunately, nobody is forced to pay attention so it is not a problem. More seriously, this thing is open source, belongs to nobody, and there is rarely a month where I do not think Okay I am tired of all this, I'll just stop working on Sage (or research) and do something useful with my life for a change (last occurrence two days ago). Though you have to understand that I worked almost daily on this Graph class for the last 3-4 years. When I am not angry I care about what happens to it. 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.
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] 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
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.
Re: [sage-combinat-devel] combinatorial statistics
Just so you know, I intend to fix the decorator at some point to reduce whatever impact it could have (I learned a bit a more about decorator while at PyCon). Our discussion about this is almost 1 year old. If you do not know how to clean this code this month, please remove it. Also, if I remember correctly we had agreed that Graph.to_partition was to be removed anyway as its meaning was totally unclear. Please open and implement a ticket for that, I will review it. This should have been done one year ago, yet nothing happened since. 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 agree, something should have been done a year ago. Cool ! But If you think it should be removed and not improved, please do it yourself. If think that If this thing, which was debated one year ago, is not to be fixed SOON, then we should get rid of it. We are already hosting code which is only useful to a couple of persons and not to Sage, we definitely should not host it forever if they abandon it ! Please open and implement a ticket for that, I will review it. I wrote the following ticket to remove Graph.to_partition. http://trac.sagemath.org/ticket/16403 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
Sorry Nathann, I don't take orders. No but you should feel responsible for the mess you add to Sage. If you want to open tickets, just do so. I don't think a ticket removing the map decorator all together would be positively reviewed right now. If you really want to know my time frame, I *intend* to work on this decorator to make it better this summer. If someone else wants to have a look on how it could be improved and open a ticket with suggestions, they're welcome. The decorator as it is is not major issue or even a bug, it's been positively reviewed years ago. Well, a positive review in Sage is just two persons agreeing together. Perhaps I could just as a friend of mine who agrees that find_start should be totally remved from Sage and let him give a positive review to my ticket ? That's why we discuss stuff, and that's why you should feel responsible when people are against what you implement. The way I remember, nothing was really agreed at the end of this endless discussion last year. If you want to open a ticket to remove graph.to_partition, just do so. http://trac.sagemath.org/ticket/16403 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
Hello ! Due to the unfortunate absence of professional programmers to write and review our code Come on, that is our job. and of mature professional mathematicians to establish clear strategic decisions for sage, we should actually as a research community be welcoming of diverse (already-coded) ideas, as long as they are not disruptive to other people's research objectives (the burden should be to prove that they disrupt). We are grown ups. If we think at some point that something should be undone, the discussion is on whether it should be undone. Not on whether we are allowed to undo things. We deprecate functions at every release, and that's healthy. And even if there were, the burden should be for anyone to _improve_ code that is considered useful by them, not remove. I said remove because waiting for one year to do something and still say I will do it later is not a good sign. Then, I remember saying in one long email that everything in FindStat seemed very cool and useful, but that we had no reason to host their code if it is not useful in Sage. Then, if it is useful in Sage, I believe that it should be made non-intrusive, i.e. the decorator should return the very function it received and not leave anything in between. This is only technical issues, nothing more. But I hate that it takes one year to see it fixed. In light of this, please reflect on the amount of mathematics you know yourself. I just read your email, and so before you begin your long enumeration let me agree with you : I am an idiot, and I know nothing. I just smiled when I read your do you know anything about categories, because funnily I am reviewing #16405 right now and wrote a couple of category tickets recently. One thing is sure: that you feel qualified to comment on it). And clearly I am wrong. Do me a favor, read this and tell me why it is made invalid by the obvious fact that I don't understand anything about categories : https://groups.google.com/d/msg/sage-combinat-devel/hupt_5776j0/KtbiHpTKXrUJ It might be that individuals feel that they understand what findstat is doing but are failing to understand the broader context, which might explain why projects like findstat, LMFDB or even sage-combinat have unnecessarily complicated relationships with the sage core itself, and why some of my contributions end up in the LMFDB code and not sage itself. Some individuals like me are bound to miss stuff forever, accept it, the world is filled with us idiots. Okay let's stop this game : all I have against FindStat is the useless methods they add (like .to_partition) and the intrusive decorator. Nothing else. Also, have you talked to Francoise and the Logilab people at the Edinburgh workshop, people who are professional developing software in the sciences to handle research results? No, I never talked to anybody named Francoise. I never talked to any JIm either. Do you know about semantic web technologies and things like that, especially as it is being applied to mathematics? Dear God, how have I failed you ? No, no I don't ! Anyways, even if you don't know about all those things, don't worry: it is actually possible, for someone with an open mind, to learn those things or at least a sufficiently general picture. Bless the Lord. 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
One use case for statistics which comes to my mind immediately is to provide answers to Just to make sure : I *NEVER* said that statistics on combinatorial objects were useless, did I ? My objections are related to the code that is included in Sage, and how it is written. http://mathoverflow.net/questions/101265/a-list-of-symmetric-statistics/101670#101670 although I have to admit that a) I asked the question myself and b) I did not give any deep reason to ask the question. Does not matter. I mean, the job of many of us is to do maths. We just need this information for our job. The whole of OEIS is useful, and a good thing, even if you find a couple of sequences there that are a bit far-fetched :-P Another use case (again for statistics) is that from time to time I encounter a set of families of objects (eg 0-1 fiillings of Ferrers diagrams of a given shape) with a natural statistic (eg. length of longest north-east chain) and then I'd like to run a brute force search whether I can find a well-known statistic equidistributed with my statistic when restricting to some family (eg., a particular shape). Statistics *ARE* useful. And we can query the OEIS from Sage, and this is cool too. Besides: is it possible to run a more exhaustive FindStat search? If I understand correctly, FindStat limits itself to 3 maps, right? I guess they can. But you see, FindStat is not exactly part of Sage, and for FindStat question the FindStat guys can answer, for they run this code, sage developpers have no hand on it :-) 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
Hello !!! I must say that I'd love to see the findstat search engine as part of sage. I would love it too. Querying the findstat database from within Sage is clearly a good thing. 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: [sage-devel] redesign combinatorial statistics
Yes I've thought of that. Yet I was the first to publish ! One year ago ... :-P https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ I'm trying to find the best way of doing it. The decorator seems the best way to flag. Before returning the orignal function, I could store the map itself. But I would like to create the map objects only if needed, and this I'm not yet sure how to do. I don't get it... What if combinatorial map just copies the list of all its parameters AND the function into a database stored in some module ? You have absolutely no other work to do, and you would only create the map objects when somebody tries to ask anything about the content of the database, don't you ? 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: [sage-devel] redesign combinatorial statistics
Let's not mix everything here. In FindStat, we do use a database for statistics (not maps) but that's not what we're talking about here. We're just talking about flagging some object methods as maps with some semantic information. Indeed. You agreed to only talk about the aspects of this decorator which are of interest to Sage. my only question is what storing the info means. I understand Nathan is suggestiong I just put it in some database object somewhere, and then my permutation object would just ask this object whenever it needs to give the list of maps. Am I right here? Let us say that when the combinatorial_map decorator is called on a function f with some parameters, it does the following from sage.combinat.combinatorial_map import my_dictionary_database my_dictionary_database[f] = list_of_parameters_or_anything_you_like return f With a design like that, any semantic information is still available if you ever need it, and the function is left unchanged. 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: sum(Composition([1,2,3])) # broken
Okay, so how should it be fixed ? Darij's ticket is 9 months old. Nathann On Monday, May 19, 2014 6:55:51 PM UTC+2, Nicolas M. Thiery wrote: On Mon, May 19, 2014 at 04:01:52PM +, Simon King wrote: Multiplication? I always think of words as elements of a free group, of course multiplicatively written. Hence, concatenation of words w1,...,wn would be prod([w1,w2,...,wn]). Indeed. `+` works too for concatenation of words, which is consistent with Python strings. But sum does not. Oh well. Cheers, Nicolas -- Nicolas M. Thiéry Isil nth...@users.sf.net javascript: 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.
Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken
Please help me follow you : You want to define a + and * operatorsfor Combinations, in such a way that Combination.sum() is not necessary anymore, which in turn means that sum(Combination([1,2,3])) would return 6 ? Nathann On 20 May 2014 10:16, Simon King simon.k...@uni-jena.de wrote: Hi Nicolas, On 2014-05-19, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Mon, May 19, 2014 at 04:01:52PM +, Simon King wrote: Multiplication? I always think of words as elements of a free group, of course multiplicatively written. Hence, concatenation of words w1,...,wn would be prod([w1,w2,...,wn]). Indeed. `+` works too for concatenation of words, which is consistent with Python strings. But sum does not. Oh well. The reason is that the sum(...) function starts the summation with zero, unless told to be differently. However, 0 is not coerced to the empy word, or to strings for that matter. If it would, summation would work. sage: W = Words(range(27)) sage: a = W([randint(0,26) for _ in range(10)]) sage: sum([a,a,a]) BOOM TypeError: unsupported operand type(s) for +: 'int' and 'FiniteWord_list' sage: sum([a,a,a],a) word: 20,17,5,14,2,14,5,9,4,21,20,17,5,14,2,14,5,9,4,21,20,17,5,14,2,14,5,9,4,21,20,17,5,14,2,14,5,9,4,21 sage: sum(['a','a','a']) BOOM TypeError: unsupported operand type(s) for +: 'int' and 'str' sage: sum(['a','a','a'],'a') BOOM # O dear... TypeError: sum() can't sum strings [use ''.join(seq) instead] Nonetheless, I think multiplicative notation should be enabled as well, as a courtesy to group theorists... But it is all not easy. I stated above, one should coerce 0 to the empty word. But then, written multiplicatively, one would coerce 1 to the empty word as well. Not very nice. Specifically if you really think of words being additive, and 5*a should be a+a+a+a+a, and not empty_word*a. Perhaps one should better say that W has a single operator (either + or *, but not both), and if + is chosen, then 5+a should not be defined, but 5*a should be a+a+a+a+a. Or if * is chosen, then 5+a and 5*a should not be defined, but a^5 should be it. In other words, one shouldn't try to coerce NN into W, but one should think of W as endowed with an NN action. And at the end of the day, I'd say that sum([a,a,a]) is a misuse of the sum() function. Best regards, Simon -- You received this message because you are subscribed to a topic in the Google Groups sage-combinat-devel group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-combinat-devel/PDPkJc_PBSE/unsubscribe . To unsubscribe from this group and all its topics, 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: sum(Composition([1,2,3])) # broken
I would rather deprecate the `.sum()` of Composition. Which means that the bug I reported will not be fixed before one year ? If you want to concatenate composition, use `+`. I do not want to concatenate compositions. I want to sum the integers that a composition contains. I use compositions as a list of integer, and I want to sum the entries. This should work : for c in Compositions(15): assert sum(c) == 15 There is also a mistake here, `__add__` is implemented instead of `_add_`. GOD. A confusion between __add__ and _add_ ? How is such a thing possible ? 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: sum(Composition([1,2,3])) # broken
I have no idea what you are talking about. I was talking about the (Python builtin?) function sum(), and I don't think it makes use of Combination.sum(). Sorry, I mean Composition, not Combination. And sum(Composition([1,2,3])) does call Composition.sum. 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: sum(Composition([1,2,3])) # broken
Yo ! I was mistaken in my previous post. Not sum() is a Python builtin, but add(). So, why do you insist on using sum() instead? The following works, and according to what you just stated, it is what you want: What the hell is add ? I did not even know this thing existed ! So, my apologies for confusing sum() with add() --- all what I stated about sum() in my previous posts applies to add()... We have to make sum work too. That's the standard Python function to add the elements on a list. Because someone ignores/hates/sabotages coercion. You mean, like the guys that give so similar names to the functions that it is impossible to notice the difference ? :-P 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: sum(Composition([1,2,3])) # broken
Hello ! Yeah, could be. But (our posts crossed) I guess you want to use add(), not sum(). I solved my problem as I usually do : I cast the combinat object to simple types to avoid these nightmares. sage: for c in Compositions(4): : c = map(int,c) # something I can trust I was just reporting here that some natural code fails on compositions, i.e. : sum(Composition([1,2,3])) 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: sum(Composition([1,2,3])) # broken
Nathann, seriously: Do you really think that Sage overriding Python's sum(), renaming it as add(), is less confusing than the requirement to implement multiplication in a ring by _mul_ rather than __mul__? What on earth could tie the two together ? sum(Composition([1,2,3])) must work, period. About having to implement _mul_ instead of __mul__, all I had to say is that giving the two methods almost the same name makes it hard to understand what the difference is. renaming _mul_ to _mul_after_coercion_ is not a design problem, it's just a function's name. It would have been a much better longterm solution to keep __builtin__.sum(). Sage may have its own summation method, but please not overriding a Python builtin. Give Sage's sum() a different name! They want to handle symbolic stuff I guess Anyway, sum(Composition([1,2,3])) must work. 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: sum(Composition([1,2,3])) # broken
In the mean time, we can implement the other approach since it makes sense anyway. Sorry but I lost you again. How can we fix this sum problem ? It seems to have triggered discussions on the additive law among Composition instances. 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: sum(Composition([1,2,3])) # broken
That way, the old behavior of sum can still be used through
{{{
sage: Compositions().sum([Composition([3,2,1]), Composition([1,2])])
[3, 2, 1, 1, 2]
}}}
+1. Or maybe instead into a multiplicative monoid? I don't have a
strong opinion either way, but we should take a consistent decision
here with words and other word-like objects supporting concatenation.
Could it be a + ? We would be consistent with words, tuples and lists.
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] sum(Composition([1,2,3])) # broken
Hello everybody ! Today I come with this : sage: sum(Composition([1,2,3])) ... TypeError: sum() takes exactly 1 argument (0 given) Some code of mine which uses Composition expected to see 3+2+1=6 there, but all I got was an exception. Looks like you are not allowed to change the meaning of .sum(), which is what Composition does. 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
Yoo !! disclaimer My answer is most likely going to be a bit broad and include stuff you already know; I am just taking the occasion to write a blurb that could possibly end up somewhere in the documentation (typically as a complement of cartesian_product?), if someone finds it useful. /disclaimer Well, if you find the question justified, of course the answer should be in the doc. There is also the problem of these __add__ and _add_. From just looking at the names you have no idea what the difference is, except if you wrote the code yourself. Now, in the graph classes we have function like add_vertex, add_vertex_unsafe, stuff like that. Wouldn't it be much better if those _add_ were renamed to something more meaningful, like _add_coerced_elements_, i.e. something that describes better what they do ? Noticing that a function is called _add_ instead of __add__ is not exactly straightforward when you don't expect it. The last player in the game is the `cartesian_product` object, as in `cartesian_product([A,B,...])`. Its role is to look at the properties of A,B,..., and decide on an appropriate concrete implementation and a category. Technically, this object is a covariant functorial construction and it's implemented in sage.categories.cartesian_product. In practice, unless one wants to use it as an example to create a new construction, there is no reason to fiddle with it. HMmm... Yeah, but it contains a class CartesianProductsCategory Why shouldn't it be taken as the definition of the CartesianProductCategory from which all other will inherit ? Thus, why shouldn't it be taken as THE place to implement things like .an_element() or .cardinality() ? - Vector spaces are already endowed with their addition. Sounds like you accidently overrode it. HMmmm... I don't get it. CommutativeAdditiveGroup is more general than vector spaces, so if something is a vector space it should inherit all addition functions from vector spaces, shouldn't they ? - Using .value directly breaks encapsulation and is thus implementation dependent. Yeah but I needed to iterate over all the coordinates of an element of a cartesian product. Does it mean that I should instead implement an __iter__ in the ParentMethods of the category they belong to ?.. I'll try that 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] Should the element of a Parent be Elements ?
This is one very special case where the Parent/Element relation is broken. First of all FiniteEnumeratedSet is not the parent of its elements (it is a facade): Well, then I am asking whether it is a good idea / should be allowed. We already have a tool to store list of elements without changing them, and it is called a list. It is also much faster. FiniteEnumeratedSet is aimed to not modify the input it gets. So if you feed it with Python objects which are not elements it will not complain and you have to go with that. With Stepan we implemented a TotallyOrderedFiniteSet which has an option for having the behaviour you expected I am not looking for a list that wraps its elements, I am writing code for the CartesianProduct category. Are you telling me that the category code has to be written without making the assumption that the elements of a parent have a .parent() function ? If so, don't we have a LOT of code to update ? 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
Yo ! The Sage developer's guide contains the following (yes, it is somewhat hidden): http://sagemath.org/doc/developer/coding_in_python.html#special-sage-functions I am sure that opening a ticket on trac to improve the docs is welcomed, for example adding the links [1] and [2] in that section. Actually improving the docs is even better :) Not everything can be documented. It is not because something is written somewhere that it will be read of that peope will know where to find it when they need it. Renaming those functions does what the doc cannot 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
Well, of course one needs to learn the language and its *context* if one wants to program something. Yes, but we want to make the language easy to work with, and easy to learn. _add_coerced_elements_ (if it makes any sense, I do not really know what its ideal name should be) is clearly more informative. If you want to program in Python, you need to learn about the magical double underscore methods, and if you do so in the context of Sage, You cannot ignore the fact that we cannot change Python and that we can change Sage. you need to learn (1) that many of the magical double underscore methods have default implementations that should better not be overridden, and (2) that in these cases the functionality is implemented in Sage by certain single underscore methods, which have an additional contract. By contract, I mean that when implementing single underscore _add_ you can assume that both arguments belong to the same parent---so, no need to do type checking in most cases. And how do you learn that,except by not understanding and asking the question here or by finding the right place in the doc ? If it were renamed, you would know what to look for. It does not replace the doc, it tells you that you need to read it to understand what is happening. And it *is* documented, e.g., in my thematic tutorial on categories and coercion. Yes, but if I see _add_ and __add__, I have no way to know which applies first/last and which deals with coerced elements. I do not even know that they are both called, as one could replace the other. Well, you know what I mean. You see _add_ and wonder what it does and think that _add_after_coercion_ or so would be a better name. But try to think from the point of view of someone who knows Python's magical double underscore methods and is aware that (as a rule of thumb!) Sage replaces them by the corresponding single underscore methods. He would understand what happens, and I would understand that something smarter than I expect is going on. Besides, it is actually *replaced* or is one called after the other ? From this point of view, don't you think that _repr_, _add_, _mul_, _rmul_ and _lmul_ are much easier to keep in mind than _default_repr_that_may_be_overriden_by_the_rename_method_, _add_after_coercion_, _mul_after_coercion_, _multiply_by_base_ring_element_from_the_right_ etc? I think that _add_after_coercion_ is better than _add_, and I don't even understand how you can think that it may be the other way around. It is clearer, how can you deny that ? Then you don't have to translate python keywords like _repr_ or _lmul_. Thus writing _addition_ instead of _add_ does not make sense, but _add_after_coercion_ *does* help. 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
Nor mine in the case of coercion and the _..._ methods :-) Because I already spent a lot of time on some pieces of the Sage infrastructure does not mean I (or anybody on sage-combinat-devel) am responsible for all of it. Which is why I suggested to report and make your case on sage-devel. I barely understand what I modify, and I still believe that I should not be the one to implement product of additive groups. If nobody feels responsible of this we have a problem. I haven't done any group theory during the last 5 years, short of some graph automorphism conversations with a friend of mine. And almost everybody else in Sage knows more than I on this respect. 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: [sage-devel] Re: Re: About _element_constructor_ of CartesianProduct
I think that the rule of thumb (if you want to implement a magical python method __bla__ in Sage, then you should check whether a default implementation exists, in which case you usually have to implement _bla_, and the documentation of the default __bla__ gives you more details what you can assume for _bla_) is way better than chosing names such as _bla_which_is_to_be_used_in_this_particular_context_. It is better only when you know the convention. And if you don't, then you will fight with bugs you do not understand until you: 1) learn it 2) give up, thinking that Sage's design is awful You need to have a good doc, but the doc does not do everything. Sometimes you do not know that some doc solves the problem you have, nor when to find it. Making these names clearer would have helped me. The point now, is that if you don't take the advice of newcomers about this, you will never see the problem again. Because now, I also know the convention and so I will never complain about this again. I will know it, no problem for me. But *MANY* times I tried to mess with categories, and every single time I gave up saying that this thing was a mess. And you have no idea how many people followed the same path before. I don't have any idea about this either. But there are things that developpers see, and other that newcomers see. 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: [sage-devel] Re: Re: About _element_constructor_ of CartesianProduct
And we shouldn't make (especially *private*) function names too verbose strikejust for newbies/strike, not just because they'd get more tedious to type, but also because code would get *harder* to read because of its length (or width). 1) I have been developping in Python/Sage for the last 4/5 years. 2) I did not understand what happened there, did not know what to look for, thus I asked on sage-devel, because I know that sage-devel exists and because I naturally write there each time I have a problem *which is not everybody's situation*. 3) I tried *MANY TIMES* to do something useful with the categories, and I systematically gave up after days of headaches and ununderstandable bugs Now, you are free to hear what you want to hear, and still believe that your conventions are best possible. I don't think I can add anything new. 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: [sage-devel] Re: Re: About _element_constructor_ of CartesianProduct
No offense at all. Oh, none taken at all ! I just wanted to emphasize that working for a long time with Python and with Sage did not necessarily help. I was mainly referring to the __foo__ vs. _foo_ part, where (I think) once you've read why they're both there, it's not necessary to restate the difference everywhere by giving the latter a different name. Well, if you know what a TSP you expect Graph.tsp() to work. We call it Graph.traveling_salesman_problem(), and even those who do not know TSP find it. I knew the Chinese Remainder Theorem but I did not know the CRT. And I believe we have a .CRT function somewhere in Sage, which rung absolutely no bell when I first saw it. 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: About _element_constructor_ of CartesianProduct
Hello ! Sorry, I was offline this morning. I just got your message saying you had fixed most of the issues in the mean time, but since this might be of general interest here is what I had already typed down. I solved my other group issues, this one has an easy workaround (wrap everything 10 times before giving it to the constructor) but it isn't solved. Throwing your _element_constructor_ code there should do the job. I know, that's what I said I was doing. But this _element_constructor_ breaks anyway. Do you have the code on some branch? I guess the issue is some typo, like a missing s to CartesianProducts. Similarly, CommutativeAdditiveGroups. A typo ? But I would get some meaningful error in this case, not this, would I ? TypeError: Cannot convert tuple to sage.structure.element.Element Autre question : quand j'ai un objet CartesianProduct, comment je recupere la liste de ses composantes, qui sont normalement des parents ? Introspection is the tool of choice to recover this kind of information. From looking at: sage: C = cartesian_product([GF(2), GF(2)]) sage: C?? or from the code of sage: C.one?? Nicolas, I can swear that in the mind of somebody who never had anything to do with categories, there is no link whatsoever between finding those sets and the function one(). When you know the answer already, it is very easy to find it again. When you don't, you spend minuteson things like this, and sometimes you even give up. In your case it's fine to use the attribute. Yeah, I found it. I don't remember how, but I did. There is a branch at u/ncohen/tmp which implements the _element_constructor_ I needed, plus order/cardinality. The order/cardinality work, but if you can tell why _element_constructor_ raises an exception and how it should be fixed, perhaps we will be able to work with products of additive groups in Sage (and other stuff too). Have fun ! 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: About _element_constructor_ of CartesianProduct
Oh, sorry, I forgot the bug report : with this branch applied, here is what happens : sage: GF(5).cartesian_product(GF(5))((5,5)) Nathann On 29 April 2014 15:48, Nathann Cohen nathann.co...@gmail.com wrote: Hello ! Sorry, I was offline this morning. I just got your message saying you had fixed most of the issues in the mean time, but since this might be of general interest here is what I had already typed down. I solved my other group issues, this one has an easy workaround (wrap everything 10 times before giving it to the constructor) but it isn't solved. Throwing your _element_constructor_ code there should do the job. I know, that's what I said I was doing. But this _element_constructor_ breaks anyway. Do you have the code on some branch? I guess the issue is some typo, like a missing s to CartesianProducts. Similarly, CommutativeAdditiveGroups. A typo ? But I would get some meaningful error in this case, not this, would I ? TypeError: Cannot convert tuple to sage.structure.element.Element Autre question : quand j'ai un objet CartesianProduct, comment je recupere la liste de ses composantes, qui sont normalement des parents ? Introspection is the tool of choice to recover this kind of information. From looking at: sage: C = cartesian_product([GF(2), GF(2)]) sage: C?? or from the code of sage: C.one?? Nicolas, I can swear that in the mind of somebody who never had anything to do with categories, there is no link whatsoever between finding those sets and the function one(). When you know the answer already, it is very easy to find it again. When you don't, you spend minuteson things like this, and sometimes you even give up. In your case it's fine to use the attribute. Yeah, I found it. I don't remember how, but I did. There is a branch at u/ncohen/tmp which implements the _element_constructor_ I needed, plus order/cardinality. The order/cardinality work, but if you can tell why _element_constructor_ raises an exception and how it should be fixed, perhaps we will be able to work with products of additive groups in Sage (and other stuff too). Have fun ! 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: About _element_constructor_ of CartesianProduct
I checked it out; at first glance, the issue is that element_constructor returns a tuple not an instance of the cartesian product. I can commit a fix in an hour or so. I wrapped it with self(tuple ...) before, and it only produced infinite loops ... 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: About _element_constructor_ of CartesianProduct
No surprise, as self(...) calls element_constructor. The amount of autmatic stuff in this code is so scary that I don't believe in anything anymore. At some point I created a function called a in a Parent which just printed a line, called it, and the result was : 1) The line was printed 2) An attribute error because some other category I had never heard about did not implement such a method I asked Nicolas if there was some caching of the categories hierarchy that was not automatically rewritten when I run sage -b. He did not answer, and I still wonder if this is true or not. To give you an idea of how scared I am of this code . 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
Well, that was a long hour. But it's now on u/nthiery/cartesian_product. Cool. I am trying to clean the CartesianProduct stuff of additive groups and it does not look good. The methods are not inherited from where they should -_- Right now, my problem is that the __add__ method from a CombinatorialFreeModule is taken from my CommutativeAdditiveGroup. And I thought I could expect all those objects to have a .value argument, but apparently I can t _ I have added the tests for list and cardinality, but not yet for element_constructor, so I don't yet guarantee correctness. ?... Okay, so I will try to see if I can guarantee correctness when you can't. I am hesitant on whether _element_constructor should always directly coerce the elements, or first check if they are already in the right parent and if not call coercion. Well, your pick. I barely understand what the dilemma is about :-P 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
Looks like it works, thanks ! sage: x=GF(5).cartesian_product(GF(5))((1,1)) sage: type(x.value[0]) type 'sage.rings.finite_rings.integer_mod.IntegerMod_int' sage: x.value[0] 1 sage: x.value[0]*5 0 Why did you have to move the code around, though ? What is the difference between sets.cartesian_product and categories.cartesian_product ? 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-devel] Re: [sage-combinat-devel] Re: About _element_constructor_ of CartesianProduct
By the way, do you know what went wrong with my banch ? Yours does not produce the error, but I have no idea why, nor what was wrong in my way of doing things... And if I do not want to do the same mistake again ?... Nathann On 29 April 2014 20:22, Nathann Cohen nathann.co...@gmail.com wrote: Looks like it works, thanks ! sage: x=GF(5).cartesian_product(GF(5))((1,1)) sage: type(x.value[0]) type 'sage.rings.finite_rings.integer_mod.IntegerMod_int' sage: x.value[0] 1 sage: x.value[0]*5 0 Why did you have to move the code around, though ? What is the difference between sets.cartesian_product and categories.cartesian_product ? 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] Organize the index of combinatorial modules
Hello everybody ! I just created a new trac ticket [1] to let us organize the index of all combinat modules. This thing is a bit hard to read : http://www.sagemath.org/doc/reference/combinat/index.html Of course I do not understand half of what all this code does, so I think the best would be for everybody to checkout this ticket and have a look, and sort his own stuff. I grouped a bit of things into categories already, you may [like/not like] it... Well, do come on the ticket and change what you like. The purpose is to give newcomers some clear idea of what can be found in the combinat code. Have fn ! Nathann [1] http://trac.sagemath.org/ticket/16058 -- 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: Organize the index of combinatorial modules
Yo !! I created http://trac.sagemath.org/ticket/14582 a while ago with a slightly more ambitious goal (and there's a patch on the old combinat queue, which I should be port to a branch). However it's fallen to the wayside as math and other code has taken priority (and because getting the doc to cross-link is a pain). So this could be a good first step towards what I had in mind for #14582. Ahahahah. I was sure that something had been created about that already. Okay, so #16058 will be a first step toward #14582. Can you group more elements from the current unsorted category ? 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: Infinite loop when comparing two crystal elements
Y ! It's not related to #14019, No of course not, but while working on it I tried to make Poset.__eq__ test equality of the two Hasse Diagram. That was a mistake, for when you test that the Hasse Diagram are equal 1) you test that the vertex set are equal 2) you test that two specific vertices are equal 3) in order to do that you test that their parents (i.e. the posets) are equal 4) You test that the two posets are equal, and loop. but a problem with = comparison in the tensor product of crystals code. I inadvertently ended up fixing this with #15882 trying to get full coverage to combinat/crystals/tensor_product.py: sage: u,v = crystals.Tableaux(['A',2], shape=[2,1])[:2] sage: u,v ([[1, 1], [2]], [[1, 2], [2]]) sage: u = v True sage: v = u False So let's finish #15882. Nathann, could you do a review of its dependency #14275? Well, I did review what I could of #15882 but that was only the catalog part of it. Now I see that you implemented a function named qdim and do so many crystal-specific things that I don't know enough to review that. About #14275 : the way it is implemented you add a deprecation feature to lazy import. But lazy imports can be used a lot, so wouldn't it be better to instead add a lazy feature to deprecation_function_alias ? This way we only touch code that is only executed when the user calls deprecated functions ?... 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: Infinite loop when comparing two crystal elements
Ahem. Of course, the graph there is totally useless :-P sage: u,v = CrystalOfTableaux(['A', 3], shape = [2,1,1])[:2] sage: u=v same result Nathann On Tuesday, April 1, 2014 4:43:20 PM UTC+2, Nathann Cohen wrote: Hello everybody ! I am just reporting a bug found on #15978 (which should make digraphs a bit faster and is otherwise totally unrelated) sage: Tab = CrystalOfTableaux(['A', 3], shape = [2,1,1]) sage: g=Tab.digraph() sage: u,v = g.vertices()[:2] sage: u = v ... RuntimeError: maximum recursion depth exceeded in cmp Looks like the same kind of stuff that happened when I was working on #14019. 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] Applying for a European H2020 grant?
AHAHAHAHAHAHAHAHAHAAHAHAHAHAHAH. So let me get this right : the plan to ask the CNRS some money in order to help you ask the Europe even MORE money, and it is assumed that a percentage of the bigger grant will go to a guy whose full-time job is to ask for money ? If there is something wrong in the world of research, I can't see it. Nathann On Sunday, March 16, 2014 10:18:12 PM UTC+1, Paul-Olivier Dehaye wrote: I am completely inexperienced with this, but: - I have heard people around me say that with this type of grant support for preparation of a grant, professional grant writers should be hired. They help write the not-so-scientific portion of the grant. - I have heard first hand from a Principal Administrator of a unit in DG CONNECT that these writers do make a difference. - I have also heard that some of those grant writers work like tort lawyers, and get paid only if the grant is funded. They then get paid some percentage of the administration budget of the grant, and that this is allowed. I can ask for more details if you would like. Paul On Sun, Mar 16, 2014 at 11:44 AM, Nicolas M. Thiery nicolas...@u-psud.frjavascript: wrote: Dear colleagues, At the occasion of a presentation of the European H2020 call for grants, I started discussing opportunities for Sage with Eugénia Shadlova (in charge of European projects at Université Paris-Sud) and Jean-Pierre Caminade (research infrastructure mission in the french research ministry). From those discussions, it seems a good bet could be the call EINFRA-9: e-Infrastructure for Virtual Research Environment. The time line would be a submission in January 2015, with funding starting 8 month after the submission. So now is a good time to start thinking about it. This in particular since the French CNRS INS2I institute is offering support (up to 5000 euros) for preparing such proposals, with an application deadline on the 21st (this Friday!). This money could be used e.g. to organize a Sage-Days this year geared toward this grant (and real work too!). European H2020 calls concern countries in Europe as well as associated countries and third countries as listed on [1]. Just to mention a couple where I can think of Sage developers and users from the top of my head, this includes e.g. Switzerland, Israel, Senegal, or South Africa. If you would tentatively be interested in joining as a participant, PI, or even better lead PI, please get in touch with me at any time, specifying: - Name, e-mail - trac github account if you have them - Status, institute (I can derive that from the main page of trac.sagemath.org if the information there is up to date) I have setup a git project for this would-be proposal [2]. A mailing list is coming too. I will add all the participants there so that they can start editing the information. The draft of project grew up from previous attempts at the scale of Sage-Combinat in France; there remains traces which should of course be cleared. Also other grant opportunities c/should be explored! (e.g. Paul-Olivier mentioned COST networks). And again: if anyone feels like taking on / sharing the lead, please!!! Please forward this to whoever might be interested. Cheers, Nicolas [1] http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-cutting-issues/international-cooperation_en.htm [2] https://github.com/nthiery/sagemath-grant-europe/ -- Nicolas M. Thiéry Isil nth...@users.sf.net javascript: 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 javascript:. To post to this group, send email to sage-comb...@googlegroups.comjavascript: . 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: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
On that note, I think reviewers shouldn't hold up tickets because they don't like the current implementation without providing a working alternative and can demonstrate why it's better. Do you think that a patch should automatically be merged when it has been waiting for a reviewer for a long time ? From time to time, I think that what a ticket implement is not a good idea. I usually say so on the ticket and refuse to review it (i.e. #13624). I still think that implementing the reviewer's remarks is the author's job, though. Otherwise you will end up with careless reviews, because the reviewers have no time to improve somebody else's code. And I wouldn't want to see careless patches either, written assuming that the reviewer will fix the problems. 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: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
Hey John no worries, I was only answering Travis' post and this (rethorical) question was just meant as a way to show that I did not concur with his view that reviewers should have to implement their remarks when the review gets long. Nathann On Tuesday, 11 March 2014, John H Palmieri jhpalmier...@gmail.com wrote: On Tuesday, March 11, 2014 12:40:41 PM UTC-7, Nathann Cohen wrote: On that note, I think reviewers shouldn't hold up tickets because they don't like the current implementation without providing a working alternative and can demonstrate why it's better. Do you think that a patch should automatically be merged when it has been waiting for a reviewer for a long time ? With regards to #10963, the ticket had been reviewed and indeed had gotten a positive review, and then some other people looked at it and started asking questions. So Nicolas is not trying to bypass the review process, but rather trying to sort out a disagreement among the various participants on the ticket. That's probably too brief to adequately summarize what's going on, but anyway, I think your question is not really relevant to this particular ticket. -- John -- You received this message because you are subscribed to a topic in the Google Groups sage-devel group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/hupt_5776j0/unsubscribe. To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscr...@googlegroups.comjavascript:_e(%7B%7D,'cvml','sage-devel%2bunsubscr...@googlegroups.com'); . To post to this group, send email to sage-de...@googlegroups.comjavascript:_e(%7B%7D,'cvml','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: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
Helloo ! I agree with John. I actually think Nicolas is quite patient trying to answer all questions. You are so kind. My suggestion would be either for Volker to implement his alternative on a different ticket, so we can see it in action and test it, or to let Nicolas' patch go in (provided of course that there are no real issues, but rather only technical disagreements about the implementation details). If we do not have Volker's alternative and we want this feature in sage, then I think the only way one could vote is for Nicolas' patch to get in! And I think we do want this feature in Sage! If you want to get this ticket inside of Sage there is an easy way : review it. The review is already going on, join it if you like (on the ticket) ! And doing this job is the only way to know if a patch is ready to get in or not. 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: Call for vote about ticket #10963: axioms and more functorial constructions
Certainly. I am not trying to vote out a reviewer. From your original post: === Call for vote - [ ] Merge this ticket, and move on with further improvements in follow up tickets [ ] This ticket should be held up until everybody is happy [ ] This ticket does not make any sense === I don't see how I this can be interpreted differently from trying to get a ticket in through a poll despite the reviewer's remarks. Really, I don't. I claim that this is the only sensible explanation. The discussion was at a stalemate due to diverging opinions on two points (a technical point; and a point about how to proceed). I am therefore bringing it on sage-devel to get *more* opinions so that we can finally get to a consensus. Still, really. I can re-read your poll a thousand times, and all I see is he does not want to change his branch despite the reviewer's remark, so he tries to force it with a poll. This already lead to some progress since this has been the occasion for laying out the positions and divergence points, and have a serene discussion about it. And the discussion is serene because it's about opinions on facts, not on people. The review is indeed a perfect place to discuss design problems. Especially when you find reviewers who actually care, which is definitely the case on this ticket. You must be ready to change the design, though. And not use the dependencies as an excuse to fix it later. I already broke it down and got merged a bunch of stuff that could go in earlier. Just look at the dependency list: #11224, #8327, #10193, #12895, #14516, #14722, #13589, #14471, #15069, #15094, #11688, #13394, #15150, #15506, #15757, #15759 (not all are mine). The list does not even show dependencies like #11935 or #715 by Simon, which were developed outside of the Sage-Combinat queue, and took a *long* time to fix because they were *hard*. Well, I regret that all those persons had to base their own work on a patch that it not in yet. Even though I hope to steer away as much as possible from category code in the future, it is quite clear from everybody's messages that they find it useful. If it is that fundamental, please don't include a piece of code that you think is not good enough or will have to be changed. The stuff that is to be implemented later often does not get implemented at all. The axiom infrastructure by itself is not splitable, and could not have gone in much earlier due to the dependencies. What makes the ticket big is the refactoring of the library using the axiom infrastructure. I believe it's helpful to review it at the same time as the infrastructure anyway because it illustrates how it works at a large scale. You don't have to agree with that, but it could not have been released earlier anyway. I just want to make sure that the code is clean and understandable for everybody (even persons to which you did not explain it in person), because I do not want to *need* your or Florent's help when I encounter a bug (like #14019 or the three broken cartesian product functions I reported some time ago). If only elected people can play with this code, it may as well be proprietary software. My only protection against that is the review process: sensible people who spend a lot of time trying to understand the code and make it clear for everybody else. If you skip it, I've got none. 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: Call for vote about ticket #10963: axioms and more functorial constructions
This ticket is holding up a bunch of other tickets that depend on it, either because they implement themselves new categories with axioms, or use features from the ones implemented here. This includes: This ticket, like every ticket on our trac server, will be merged when the reviewers will be happy with it. Period. If you have any problem with that, please remember the times you were told that Sage-combinat was a fork of Sage, and too expensive to maintain. If you got other persons in trouble because of that now that Sage uses git, you are the only one to blame. You can be sorry, but that is no reason to merge anything before the reviewers (=not me, I don't get half of what this ticket is about) are happy. Respect that. Don't attempt to short-cut the review process with polls. Let's not deviate even more from incremental development and the usual release early, release often. Is that a f*** joke ? Your ticket was created three years ago, and the branch is thousands of lines long. Sage-combinat is all about not releasing early and often. It's about keeping it all unreviewed for months while you work on it, before creating a patch-bomb ticket on Sage's trac server. If you had worked incrementally this would have been settled ages ago, not at the last minute. Nathann On Friday, March 7, 2014 1:14:44 PM UTC+1, Nicolas M. Thiéry wrote: Dear Sage developers, This is a call for vote about the ticket: #10963: axioms and more functorial constructions [1] Sorry this post is long; it's trying to give a fair summary of the huge discussion on [1]. Here is the table of contents: - What is the ticket about - Relevance - History - Debate - Personal opinion - Call for vote What is the ticket about The main feature implemented by #10963 is an infrastructure for axioms which enriches the current category infrastructure. Namely, if you have a category, you can now ask for the (full) subcategory of the objects satisfying a given axiom. For example: sage: Groups().Finite() Category of finite groups Of course, this can be iterated: sage: Magmas().Associative().Commutative().Unital().Inverse() Category of commutative groups By itself this is a little improvement, since it gives for example a single entry point for all the variants of groups (or of magmas, ...); in particular this will allow, as a later step, to remove a lot of stuff from the global name space. This is in line with what we already have for functorial constructions: sage: Groups().CartesianProducts() Category of cartesian products of groups What's really new is that axioms play nicely with intersection: sage: Groups()Magmas().Commutative()Sets().Finite() Category of finite commutative groups sage: (CommutativeAdditiveGroups() Monoids()).Distributive() Category of rings sage: Rings().Division()Sets().Finite() # Wedderburn's theorem Category of finite fields Fine, this is cute, but why is this relevant? Relevance - As time passes, the hierarchy of abstract classes for parents, elements, and morphisms in Sage is getting larger and larger. From the beginning, the purpose of categories in Sage has been to exploit the strong semantic provided by the math to keep such large hierarchies maintainable. The key is to fight hard against duplication and toward single point of truth. Just as a trivial example, Sage deduces automatically from the above that the abstract class for finite groups (Groups().Finite().parent_class) should inherit from the abstract class of groups and the abstract class of finite monoids. Axioms are an important step to scale further by controling the potential combinatorial explosion of the number of classes and categories. For details, see the section on axioms in the primer [2]. History --- The work on this ticket started three years ago, growing up out of strong immediate needs for the hierarchies of categories appearing in the representation theory of semigroups or Hopf algebras. But the infrastructure is also beneficial for non exotic categories like the ones we have seen in the examples above. For example, it made it practical to implement categories for the many variants of algebras (unital or not, associative or not, commutative or not, ...) For the design of the category infrastructure, we had some strong source of inspiration from other systems like Axiom, MuPAD, or Magma. As far as I know, no other system has a non trivial axiom infrastructre like this one. Which means that it took a long time -- three years -- to analyse the needs, explore potential idioms, and implement and reimplement the infrastructure until it felt right. It also took as a prerequisite to fix a bunch of technical hurdles, in particular #11935 and #13589 (thank you
[sage-combinat-devel] Re: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
sage: P = Parent(category=Cs().Finite()) sage: P.foo() # ok, nice I am a method on finite C's sage: P.is_finite() # Where does that come from? True Is this method named 'is_finite' because the axiom's name is finite ? If the axiom is HeyHeyHey will the .is_heyheyhey method be defined ? I am trying to understand, and I remember you mentionned something about the name of a class being used some time ago... If so, what is the point of defining this function ? It always returns true, and if you try .is_finite() on an object which does not have Finite as an axiom you are meant to interpret AttributeException as a I do not know ? 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] sage-combinat poster
Graphs are not part of Combinat. Nathann On Sunday, January 26, 2014 10:53:49 PM UTC+1, Nicolas M. Thiery wrote: On Thu, Jan 23, 2014 at 09:55:23AM -0800, Anne Schilling wrote: It is time to update our poster again! The current poster can be found at http://combinat.sagemath.org/misc/file/b82a003ca596/articles/2013-01-17-Poster/main.pdf If you have any updates or suggestions for improvements, please let me know! I implemented a few last October, and am about to implement a few more right now. Please double check the contributors list! Does 100 sound about right for the number of publications using Sage-Combinat? By the way: at the occasion of lab evaluations, Teresa made a light version of the poster, both in French and English: http://igm.univ-mlv.fr/~teresa/2013octPostersAERES/CombinatoireAlgebrique/SageCombinat2013_FR.pdf http://igm.univ-mlv.fr/~teresa/2013octPostersAERES/CombinatoireAlgebrique/SageCombinat2013_EN.pdf Note that they are dedicated to Alain; we could possibly do the same for ours. Cheers, Nicolas -- Nicolas M. Thiéry Isil nth...@users.sf.net javascript: 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/groups/opt_out.
Re: [sage-combinat-devel] sage-combinat poster
It would be nice to have (part of) http://steinertriples.fr/ncohen/tut/LP_examples/ on the poster !! You think there is a link between LP and Hopf Algebras ? :-P 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/groups/opt_out.
[sage-combinat-devel] Doc does not build
Hello everybody ! Right now with beta4, I get the following when I try to build the doc of combinat/ --- [combinat ] building [html]: targets for 247 source files that are out of date [combinat ] updating environment: [config changed] 255 added, 0 changed, 0 removed [combinat ] Sphinx error: [combinat ] 'ascii' codec can't decode byte 0xe2 in position 939: ordinal not in range(128) Build finished. The built documents can be found in /home/ncohen/.Sage/src/doc/output/html/en/reference/combinat --- Given how I patched that folder recently it may totally be my fault, this being said I have no idea if anybody encounters the same problem, and if anybody has any idea of how to fix it. I don't even know which file may contain the bad character :-/ Thanks for your help ! 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/groups/opt_out.
[sage-combinat-devel] Re: Doc does not build
Sorry, it looks like my local Sphinx had a problem. Removed output/, build again, and it works. I love this program. And sorry for the noise :-/ 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/groups/opt_out.
Re: [sage-combinat-devel] Dear Poset Users, tell me what you like
Helloo ! So it's good to not compute the transitive closure by default, at least not for large posets, and instead have some idiom to state this poset is small enough and I am about to do many comparisons; go ahead, compute the transitive closure. Given that the current idiom is pretty obscure, you should feel free to change it to something better. Well. Actually, you already compute a *LOT* of information right when the Poset is built. The Hasse Diagram is not built for free, and the call to transitive_reduction can involve more computations than what is neded for the transitive closure already. Especially since this closure can be computer in pure C code with no vertex labels. How do you build most Posets ? Here is the code that builds a poset from a list of vertices and a function : for x in elements: for y in elements: if function(x,y) is True: relations.append([x,y]) So the transitive closure is computed for free here. Even though you recompute it from the transitive reduction, later, if the user asks. Perhaps we could just save the information when it really is for free, and try to find a new trick to warn the user that he should have been pre-computing the transitive closure before doing many comparisons. 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/groups/opt_out.
Re: [sage-combinat-devel] Dear Poset Users, tell me what you like
Yoo !! Perhaps we could just save the information when it really is for free, and try to find a new trick to warn the user that he should have been pre-computing the transitive closure before doing many comparisons. Hmmm.. I think there is a problem there : the transitive reduction is computed in a Poset *function*, which then gives its cleaned input to the FinitePoset constructor. And this thing is UniqueRepresentation. Does it mean that I cannot give it, along with the Hasse Diagram, the transitive closure if I have it ? Right now, I fear that it would mean that two posets would be declared different, if one was built along with a transitive closure and not the other. Other problem : right now #14589 is only a C data structure. No Python involved. And Posets are a pure Python class. HasseDiagrams too. H 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/groups/opt_out.
Re: [sage-combinat-devel] Dear Poset Users, tell me what you like
Sorry everybody. I thought these french emails were just exchanged between us. I didn't mean to send it to the forum. Sorry for that :-/ Nathann 2014/1/9 Nathann Cohen nathann.co...@gmail.com: 80% de mon mail était de l'aide technique, et les 20% de remerciements ne m'ont pas pris du temps que j'aurais pu consacrer à autre chose. Maintenant si tu préfères que je commence mes mails par des insultes, je peux aussi! Je crois que je préfère les insultes, au moins ca fait avancer les choses. Maintenant pour l'aide technique tu repasseras, ce mail c'est pour vous demander d'écrire votre liste au père Noel. C'est un thread dans lequel je vous demande comment vous voulez que je tune vos posets pour vous. Répondre à un mail comme ca c'est pas exactement ce qu'on peut appeler une aide technique :-P Oui, je sais! Moi aussi j'ai du mal à faire reviewer mes patches. Ouais mais les tiens c'est des patch bomb. Quant au commentaire sur la doc, tu peux te le mettre ou je pense. Les 2/3 du patch, c'est de la doc. Alors je suis d'accord que ce n'est pas suffisant: le travail d'infrastructure est un domaine particulièrement exigeant au niveau documentation. Il y aura encore du travail à faire après le patch. Mais dire que «je me dispense d'écrire la doc», ça me donne envie de distribuer des coups de poings. Heuuu... Ouais, mais là vraiment tu te dispenses d'écrire de la doc. Tu dis toi même dans les commentaires Altogether, I think it's worth keeping the feature. The implementation is definitely disputable and any further improvement is more than welcome: simplified logic, better error handling, documentation, ... But maybe we can consider it good enough for now. Bah non, on considère pas good enough for now un patch dans lequel il manque de la doc. Je vois pas pourquoi. C'est pas parce que c'est exigeant que ca te donne le droit de pas le faire. Surtout quand y'a déjà de la doc en retard que tu dois écrire (je crois qu'on avait échangé des mails là-dessus y'a pas longtemps), et que j'ai personnellement pas confiance quand tu me dis que tu vas le faire. Et que j'ai probablement des exemples à faire valoir. Je sais parfaitement qu'il y a un besoin énorme de review. Si tu veux une réponse du berger à la bergère, j'ai plus besoin de toi pour déposer un projet ANR pour me payer une délégation que pour me libérer du temps que pour me faire culpabiliser. Si tu veux que je t'aide à faire un truc, t'as juste à demander. Tu ne m'as jamais demandé si je voulais t'aider à écrire à une ANR, tu m'as demandé si je voulais en faire partie, et j'ai répondu que tu pouvais mettre mon nom dessus si ca t'aidait. Si tu me demandes de t'aider à écrire un truc (et si tu penses que je peux le faire bien, ca j'en ai aucune idée), dis moi quoi et je le ferai de mon mieux. Et vite, probablement, parce qu'en ce moment je me prends la tête sur un problème débile de graphe que j'arrive pas à résoudre. Mais y'a deux trucs clairs 1) Je ne veux pas bénéficier de la thune 2) C'est moi qui te rend un service en aidant à l'écrire, pas toi qui me rends un service en me laissant entrer sur ton ANR Franchement, je ne vois aucun problème à t'aider à écrire ton pdf d'ANR. Franchement aucun. Je veux juste qu'il soit bien clair que je le fais pour aider un pote, pas pour toucher à leur blé. C'est tout. Et que bien entendu, ca ne m'engage pas à refaire le taf dans le futur si jamais j'avais pas envie. J'ai passé une bonne semaine en décembre dernier à bosser sur le dossier CNRS d'un mec qui postule cette année. J'ai rien a gagner là-dedans, j'aide juste un pote. Ca je le fais avec plaisir. Donc si je peux faire un truc pour ton ANR commence par me dire quoi, moi je ne vois pas le problème. Par contre, dans le principe, si tu te retrouves a choisir entre faire du taf Sage nécessaire (ou de la recherche) et remplir des demandes d'ANR, c'est que tu ne devrais pas remplir des demandes d'ANR. Sérieusement: ton mail viens de m'énerver et me faire perdre 15 minutes, alors que j'étais en train d'écrire de la putain de doc. Si on compte mes gueulantes quand je patch le dossier combinat/ c'est toujours toi qu'es dans le rouge :-P 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/groups/opt_out.
Re: [sage-combinat-devel] Re: About Free Algebras, infinite Words and equality
You are right. Infinite words don't belong into an algebra; you cannot multiply them. Barring hack reasons, the change is correct. HMmm... And what do you think of Shuffle Algebras on infinite words ? Is this one correct or not ? It looks okay to me.. But if you tell me that it is not for yet another reason it will make my debugging *much* easier :-P 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/groups/opt_out.
Re: [sage-combinat-devel] Re: About Free Algebras, infinite Words and equality
Okay, I just created an element manually instead of calling an_element(). Nathann On 5 January 2014 15:59, Nathann Cohen nathann.co...@gmail.com wrote: You are right. Infinite words don't belong into an algebra; you cannot multiply them. Barring hack reasons, the change is correct. HMmm... And what do you think of Shuffle Algebras on infinite words ? Is this one correct or not ? It looks okay to me.. But if you tell me that it is not for yet another reason it will make my debugging *much* easier :-P Nathann -- You received this message because you are subscribed to a topic in the Google Groups sage-combinat-devel group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-combinat-devel/zdN44XJZu5s/unsubscribe . To unsubscribe from this group and all its topics, 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/groups/opt_out. -- 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/groups/opt_out.
Re: [sage-combinat-devel] Re: About Free Algebras, infinite Words and equality
H... I just had Nicolas on the phone who told me that both can be changed to finite words only. Aand he had Florent around to confirm. I also think that the concatenation product is not well defined. And I actually wrote that in the patch already :-/ On the other hand I did not touch the Shuffle Product. Well, tell me what you think ^^; Nathann On 5 January 2014 19:09, Darij Grinberg darijgrinb...@gmail.com wrote: Huh? I thought shuffle does not work (because ... sh ... would be a sum of infinitely many identical words), but uv is well-defined (and equals u when u is infinite)? On Sun, Jan 5, 2014 at 7:08 PM, Christian Stump christian.st...@gmail.com wrote: Yes, but it's associative, so it works... (Except I don't expect it to have much of a use.) can you be more specific? How is the product uv defined? I see that you have a shuffle product defined, but I don't see that you have concatenation... 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/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups sage-combinat-devel group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-combinat-devel/zdN44XJZu5s/unsubscribe . To unsubscribe from this group and all its topics, 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/groups/opt_out. -- 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/groups/opt_out.
Re: [sage-combinat-devel] Re: About Free Algebras, infinite Words and equality
The shuffle algebra is not well defined on infinite words (the product becomes an infinite sum). So please turn infinite=False in both situations. Okay... So I will edit #12867 again :-P 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/groups/opt_out.
Re: [sage-combinat-devel] Re: About Free Algebras, infinite Words and equality
I just edited ticket #12867. Thank you for your help :-) 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/groups/opt_out.
Re: [sage-combinat-devel] Re: Review needed for some combinatorial constructions
Hello !!! I'm starting to get interested research-wise in this stuff. *Great* news (for me) :-PPP When trac was reasonably fast, I looked them over and the formatting/documentation looked fine. It seemed like Dima has looked at them as well? Now trac is so slow, and since the review system has changed from hg to git, I'd have to look up how to apply patches and test. Come n ! You'll see, Git is cool and very coherent. Plus it's cool combinatorial stuff, I need help ! I have code code of my own testing+constructing weighted PDSs (essentially association schemes). HM.. I don't know what those are O_o 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/groups/opt_out.
[sage-combinat-devel] .rank() returns None when the element is not in self.
Hello everybody !
Federico found in #15609 that the following returned nothing :
sage: Derangements(3).rank(Wouhou)
I thought at first that it was a stupid mistake, but it turns out that the
documentation of this rank function explicitly says that None is returned
when the element is not found.
Well. Now, most other realistic implementations of rank (the ones which do
NOT enumerate the possibly exponential set, not to say infinite) will throw
an exception in some unexpected situations.
sage: Combinations(4,3).rank('Hey')
...
ValueError: 'H' is not in list
Thus, is there any sensible reason for not raising an exception when the
element is NOT found ?
The current code is :
counter = 0
for u in self:
if u == x:
return counter
counter += 1
return None
By the way, and even though it is not the subject, I am totally against
things like these automatic __contains__ and rank function that enumerate
all elements of a set, hoping to find the right one. This code always takes
a lifetime, and I consider the NotImplementedException that would be
returned if these implementations did not exist as a *service* giving me
the information that there is no sensible implementation available.
sage: Derangements(999).rank(Hey)
...
...
...
What's the point ?
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/groups/opt_out.
Re: [sage-combinat-devel] Dear Poset Users, tell me what you like
Would you mind telling me what huge means ? It does make a difference when one writes the code. Probably with hundreds of vertices. That's huge ? Okay I see. I'm glad I asked. So it's not larger than 65536 :-P This was only for you to see what the graphs look like :-) Well, ... sage: P = Poset(([1,2,3],[[1,2]])) sage: L = P.linear_extensions() sage: G = L.markov_chain_digraph() sage: view(G) ... NotImplementedError: it is not possible create a tkz-graph version of a graph with multiple edges By the way it would be cool if somebody could review #14953 as it could be useful to you too. As well as #14589 because that's what I think should be used to store the transitive closure of your posets and make the comparisons faster. 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/groups/opt_out.
Re: [sage-combinat-devel] Dear Poset Users, tell me what you like
Y !! I certainly can recall dealing with lots and lots of small posets (typical for algebraic combinatorics: your combinatorial objects are small, but you are often considering all of them at once because you are talking formal linear combinations of them and likewise). I also have dealt with medium-size posets (30 to 40 vertices), but in those cases I don't think the comparisons were much of a bottleneck. I don't recall ever dealing with huge posets (as in thousands of vertices), but I can imagine myself doing that every once in a while. On another note: I remember the __init__ of Poset (well, FinitePoset) being way slower than it reasonably should be. I think this is related to it ducktyping the input (which IMHO is a bad thing anyway but seems standard in Sage). It would be nice to have quicker ways to initialize a poset from an already sanitized/predigested input datastructure. This all said, I'd very much like to see things not getting slower in the less-used regime while the more popular regime gets optimized. I see. Thank you very much for this informative answer ! This duck typing I think is standard in Sage-combinat, but not in the other parts of Sage that I know (which may be very few, admittedly). I also think that this is where most of your ressources go when you use Posets, and that there should be a way to disable it. For some operations in graphs most of the time is spent dealing with labels, especially when they are complicated and hard-to-hash things. Let me withdraw what I said above about code getting slower at first : it turns out that the code I thought would have to be re-written for the new immutable backend already works fine with this backend, so using this new backend should only make things faster. Rewriting this code for this specific backend should be even better. Right now, what I wonder is the following : #14589, when it will be reviewed (please, help me !), can be used to store efficiently in memory a dense digraph, and in this context the transitive closure of your Poset. Which means that comparing two elements will just amount to check that a bit is set to 1, which is *FAST*. Most of the time should be spent translating the vertex's label to an integer, but well, it should be fast. The question is : when should this transitive closure be computed ? Should it be computed when when the first comparison is requested ? I guess that this would make this ._transitive_closure a lazy attribute of Posets. Or should it be computed when the user explicitly asks for it ? It would mean that a keyword could be added to the Poset constructor, somehow asking the user which data structure should be used to store it : only hasse diagram, or the transitive closure too ? I wonder. It may be better to compute it immediately when a comparison is tried, but that would mean a huge slowdown if you build a lot of posets, compare two elements and throw them away. It should be much faster if you compare a lot of things on the same poset. What do you think ? Have fuunnn !! 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/groups/opt_out.
Re: [sage-combinat-devel] Dear Poset Users, tell me what you like
Hmmm... Looks like there is already something like that in .hasse_diagram, in the _leq_matrix() method : def _leq_matrix(self): ... # Redefine self.is_lequal self.is_lequal = self._alternate_is_lequal ... Though this Matrix is defined to be a sparse matrix defined on ZZ. Don't know how much faster comparisons can be with a real binary matrix. Right now, it looks like it is created when the users asks for the matrix, and when he tests whether to elements are comparable/incomparable. So it's not sure somebody who would like to compute many comparisons would end up creating this matrix. Hmmm... Wonder what should be done there... O_o Nathann On 31 December 2013 11:29, Nathann Cohen nathann.co...@gmail.com wrote: Y !! I certainly can recall dealing with lots and lots of small posets (typical for algebraic combinatorics: your combinatorial objects are small, but you are often considering all of them at once because you are talking formal linear combinations of them and likewise). I also have dealt with medium-size posets (30 to 40 vertices), but in those cases I don't think the comparisons were much of a bottleneck. I don't recall ever dealing with huge posets (as in thousands of vertices), but I can imagine myself doing that every once in a while. On another note: I remember the __init__ of Poset (well, FinitePoset) being way slower than it reasonably should be. I think this is related to it ducktyping the input (which IMHO is a bad thing anyway but seems standard in Sage). It would be nice to have quicker ways to initialize a poset from an already sanitized/predigested input datastructure. This all said, I'd very much like to see things not getting slower in the less-used regime while the more popular regime gets optimized. I see. Thank you very much for this informative answer ! This duck typing I think is standard in Sage-combinat, but not in the other parts of Sage that I know (which may be very few, admittedly). I also think that this is where most of your ressources go when you use Posets, and that there should be a way to disable it. For some operations in graphs most of the time is spent dealing with labels, especially when they are complicated and hard-to-hash things. Let me withdraw what I said above about code getting slower at first : it turns out that the code I thought would have to be re-written for the new immutable backend already works fine with this backend, so using this new backend should only make things faster. Rewriting this code for this specific backend should be even better. Right now, what I wonder is the following : #14589, when it will be reviewed (please, help me !), can be used to store efficiently in memory a dense digraph, and in this context the transitive closure of your Poset. Which means that comparing two elements will just amount to check that a bit is set to 1, which is *FAST*. Most of the time should be spent translating the vertex's label to an integer, but well, it should be fast. The question is : when should this transitive closure be computed ? Should it be computed when when the first comparison is requested ? I guess that this would make this ._transitive_closure a lazy attribute of Posets. Or should it be computed when the user explicitly asks for it ? It would mean that a keyword could be added to the Poset constructor, somehow asking the user which data structure should be used to store it : only hasse diagram, or the transitive closure too ? I wonder. It may be better to compute it immediately when a comparison is tried, but that would mean a huge slowdown if you build a lot of posets, compare two elements and throw them away. It should be much faster if you compare a lot of things on the same poset. What do you think ? Have fuunnn !! 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/groups/opt_out.
[sage-combinat-devel] Dear Poset Users, tell me what you like
Hell guys !! Yesterday Simon finished dealing with #15278, which defines equality and hash methods for immutable graphs. That's a good news for the combinat/ code, as it now uses an ugly hack to pretend that non-immutable graphs are immutable, and that's a mess. A mess that we will be trying to clean soon if we can, by the way. The thing is that we may eventually replace the combinat/ fake immutable graphs with real immutable graphs. That should make it MUCH lighter in memory, and theoretically faster. Theoretically, because it may not be at first, but that's another problem. My point is the following : I need to know what you do with Posets, in order to use the best data structure. Theoretically, he is the problem : - sparse backend means linear-time comparisons of elements. - dense backend means that comparison of elements is a dictionary lookup (it would be constant time if not for those cursed vertex labels) Thus, I would like to know the size of posets you deal with. Do you often deal with small and many posets ? Do you deal with HUGE posets (what's the max size) ? What do you do with them ? Do you compute many comparisons on the same given poset, or do you do just one before throwing it away ? And what's the most time consuming operations you have to pay for ? Any answer to those questions would help me find out what's best to store data in Posets. And please answer them all if you can. All of you. And by the way, it would be great if somebody could review this ticket, because I can't do anything for you without that : that's the dense immutable graph backend. http://trac.sagemath.org/ticket/14589 Have fun everybody !!! 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/groups/opt_out.
