[sage-combinat-devel] quasisymmetric functions + lisp compiler
Hi! Sara asked me today what the current functionalities of quasisymmetric functions are in sage. Jason is working on this, right? Also, is there an interface with the lisp compiler sbcl? Cheers, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Inversion of a triangular module morphism
I was actually wondering if there were a specific need for the inverse to be from the same type as the original morphism, in this case, a triangular morphism on basis. If there is none, the fixing should be quite easy by creating method morphism with the preimage function (with maybe an optionnal argument to force the inverse on basis when needed). 2010/12/1 Nicolas M. Thiery nicolas.thi...@u-psud.fr: Hi Vivianne, On Wed, Dec 01, 2010 at 03:31:51PM +0100, Viviane Pons wrote: dealing with my multivariate polynomials on multi bases, I had a look into the code of TriangularModuleMorphism especially the part that inverse a triangular morphism defined on the basis. The method preimage is working well and uses the usual algorithm to inverse triangular morphim. However, where you create a morphim on basis and ask for its inverse using the __invert__ method, it creates another morphism on basis where the on basis method is actullay the preimage of the first morphism. This is not efficient at all and is making my inverse morphisms really slow. The preimage should be used on the global element and not on basis elements. It is even written as a comment that it is not well implemented : # This should be removed and optimized (the inverse should not be computed # on the basis An example on where the inverse morphism is unefficient : sage: A = AbstractPolynomialRing(QQ); sage: Schub = A.schubert_basis_on_vectors(); sage: pol = Schub[3,2,4,5,6].expand() sage: mor = Schub._finite_basis(5)._morphism sage: inv = mor.__invert__() sage: time mor.preimage(pol) CPU times: user 0.33 s, sys: 0.00 s, total: 0.33 s Wall time: 0.33 s Y(3, 2, 4, 5, 6) sage: time inv(pol) CPU times: user 243.01 s, sys: 0.04 s, total: 243.04 s Wall time: 243.06 s Y(3, 2, 4, 5, 6) Here mor is the morphism that transform a Schubert polynomial into a sum of monomials elements. The Schubert polynomial I chose is quiet big so there is a lots of elements in the sum. the preimage method takes the dominant monomial and develop the corresponding schubert and sees right away that the development corresponds to the entire polynomial : so it's really quick. Whereas the inverse morphism is actually transforming each one of monomial elements into a a sum of Schubert polynomials which takes for ever... So my questions are: is there a reason it is implementing like that ? Is there a plan to change it ? What has to be done for that to be changed and nothing beeing broken ? The TODO says it all: this should be fixed, and what is needed is a volunteer! There is a single case where doing things on basis is useful: if one wants to cache the result (in other words to progressively compute the matrix of the inverse morphism). I would need to dig into the code to see what exactly needs to be done. But feel free to improvise whatever feels natural. As far as I remember, the code is tested rather intensively, so that should be a safe refactoring. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] quasisymmetric functions + lisp compiler
Hi Anne, On 12/07/2010 03:25 AM, Anne Schilling wrote: Hi! Sara asked me today what the current functionalities of quasisymmetric functions are in sage. Jason is working on this, right? Yes. Currently, in sage-combinat, one can convert back and forth between the monomial and fundamental bases. One can also convert a symmetric function to quasisymmetric, and vice-versa (provided the qsym function is symmetric, of course). None of this is in sage, yet. Also, is there an interface with the lisp compiler sbcl? I think a lisp compiler is available (this is how Maxima is compiled) and I don't think it's sbcl. But I don't know for sure. -Jason -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] quasisymmetric functions + lisp compiler
Hi Jason, Sara asked me today what the current functionalities of quasisymmetric functions are in sage. Jason is working on this, right? Yes. Currently, in sage-combinat, one can convert back and forth between the monomial and fundamental bases. One can also convert a symmetric function to quasisymmetric, and vice-versa (provided the qsym function is symmetric, of course). None of this is in sage, yet. Great! Could you send me some sample code? One problem I currently have with the sage-combinat queue is that then I cannot show any poset pictures, but tomorrow I won't have to .. I think a lisp compiler is available (this is how Maxima is compiled) and I don't think it's sbcl. But I don't know for sure. Thanks. Off to Microsoft now (I should not miss the bus), Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-devel] Re: buildbot testing documentation
On Mon, Dec 6, 2010 at 8:43 PM, Niles nil...@gmail.com wrote: On Dec 6, 10:53 pm, Jason Grout jason-s...@creativetrax.com wrote: Robert (and whoever else is working on the buildbot [1]), First of all, THANK YOU!!! This is amazing! I love how it is hooked up to show the status on trac. Indeed -- THANKS ! ! ! Your welcome. Could we add building documentation to the things that it checks for each ticket? Done. I have a couple of other feature requests/suggestions, which of course you're welcome to ignore since this is already great work! But if you're interested, here are my thoughts: One of the next steps is to get this cleaned up enough to get into Sage, so people can start improving it and running it on their own machines. The way it's set up is that there's a single server that can handle any number of build slaves. 1. When I visit the buildbot page for a particular ticket, I think it would be useful to show, in addition to the build/test history, the list of patches which buildbot plans to apply on its next run -- this would help people verify that the correct attachments/dependencies are computed by buildbot without having to just wait for the next run. The patches it intends to apply are exactly those listed at the top of the page. 2. It might be nice to know when buildbot plans to test the ticket next -- even a rough estimate would be helpful so that reviewers can determine if it would be more efficient for them to build and run tests themselves or wait for the buildbot That's an interesting idea, but it's not easy to expose that information. The way it works is that a build slave requests a list of tickets, rates them according to its own internal settings (which may be different for each bot), and then starts on a ticket (notifying the server to avoid overlap). I suppose as well as a pending field list, one could add something that collects different bots ratings at different points in time and their respective speeds and does an estimate. Ideally, as well as the main buildbot that just churns through tickets, this would be incentive for people to run their own private buildbots according to their interests (it can be configured to give priority to components, authors, etc). I also intend it to be very easy to run a bot on a list of tickets, which isn't as good as having the results up there right away, but better than doing things manually (and the results are shared). Of couse we can't all be pounding away on sage.math with -tp 12... 3. It seems that there are 2 or 3 tests that consistently fail, and which most people ignore for the purposes of reviewing (e.g. the startup.py test for startup time on sage.math.washington.edu). This means that probably no ticket will ever have TestsPassed status, and the TestsFailed status is less useful because it doesn't distinguish between failures which indicate a ticket needs more work and failures which should be ignored (for the purposes of reviewing, that is). I don't really want to reignite the debate about whether these tests should be modified or not, but perhaps buildbot could have a separate status when the only doctest failures are from among a certain set of files -- this would give more useful information to reviewers. Yes. Though it's potentially dangerous to filter on files rather than individual doctests. The first step would be to establish a baseline for each server, but beyond that I probably won't have time to implement much in the near term. 4. On a similar topic, I think someone else suggested that the failure summary from doctests could be posted directly to each buildbot ticket page -- for most people, that's probably the only part of the log that's really important. Well, coverage is nice, to look at too. For sure there'll be a summary log like David Roe requested, but I'd also like each machine report to be somewhat compact so one can more easily see the results of several machines. Certainly worth experimenting with. There's probably a wealth of data that can be extracted by (1) analyzing the sources before and after and (2) analyzing the full log, and I'm hoping it won't be too hard for people to play with that. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] graph theory: refactor implementation of spanning tree algorithms
I'm not sure it is a good idea to *remove* the methods from the object of which they are a natural function. I've seen this argument many times before, and I really like this as an organizing method. Everything else you say seems like a good idea to me: improving the documentation, having the actual implementations in their own module, cleaning up source code, making it all more accessible. I think you can accomplish all these goals without unbloating graphs. I think Sage users have gotten used to (please feel free to correct me on this, Sage users!) looking for a method via tab completion. I worry about how many features we have for graphs already which I have seen users surprised to find. Cleaning up documentation might make more people more aware of what Sage can do, but I think moving these methods (at least in name) out of the graph classes would be a push in the other direction. -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: buildbot testing documentation
On Tue, Dec 7, 2010 at 2:41 AM, Robert Bradshaw rober...@math.washington.edu wrote: On Mon, Dec 6, 2010 at 8:43 PM, Niles nil...@gmail.com wrote: On Dec 6, 10:53 pm, Jason Grout jason-s...@creativetrax.com wrote: Robert (and whoever else is working on the buildbot [1]), First of all, THANK YOU!!! This is amazing! I love how it is hooked up to show the status on trac. Indeed -- THANKS ! ! ! Your welcome. Could we add building documentation to the things that it checks for each ticket? Done. I have a couple of other feature requests/suggestions, which of course you're welcome to ignore since this is already great work! But if you're interested, here are my thoughts: One of the next steps is to get this cleaned up enough to get into Sage, so people can start improving it and running it on their own machines. The way it's set up is that there's a single server that can handle any number of build slaves. 1. When I visit the buildbot page for a particular ticket, I think it would be useful to show, in addition to the build/test history, the list of patches which buildbot plans to apply on its next run -- this would help people verify that the correct attachments/dependencies are computed by buildbot without having to just wait for the next run. The patches it intends to apply are exactly those listed at the top of the page. 2. It might be nice to know when buildbot plans to test the ticket next -- even a rough estimate would be helpful so that reviewers can determine if it would be more efficient for them to build and run tests themselves or wait for the buildbot That's an interesting idea, but it's not easy to expose that information. The way it works is that a build slave requests a list of tickets, rates them according to its own internal settings (which may be different for each bot), and then starts on a ticket (notifying the server to avoid overlap). I suppose as well as a pending field list, one could add something that collects different bots ratings at different points in time and their respective speeds and does an estimate. Ideally, as well as the main buildbot that just churns through tickets, this would be incentive for people to run their own private buildbots according to their interests (it can be configured to give priority to components, authors, etc). I also intend it to be very easy to run a bot on a list of tickets, which isn't as good as having the results up there right away, but better than doing things manually (and the results are shared). Of couse we can't all be pounding away on sage.math with -tp 12... 3. It seems that there are 2 or 3 tests that consistently fail, and which most people ignore for the purposes of reviewing (e.g. the startup.py test for startup time on sage.math.washington.edu). This means that probably no ticket will ever have TestsPassed status, and the TestsFailed status is less useful because it doesn't distinguish between failures which indicate a ticket needs more work and failures which should be ignored (for the purposes of reviewing, that is). I don't really want to reignite the debate about whether these tests should be modified or not, but perhaps buildbot could have a separate status when the only doctest failures are from among a certain set of files -- this would give more useful information to reviewers. Yes. Though it's potentially dangerous to filter on files rather than individual doctests. The first step would be to establish a baseline for each server, but beyond that I probably won't have time to implement much in the near term. And on this note, I feel that a test that's expected to fail is a bad test--we really need to get to the bottom of this sage0 failure and improve startuptime, hopefully this'll provide some more motivation :). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] graph theory: refactor implementation of spanning tree algorithms
Hi Robert, On Tue, Dec 7, 2010 at 9:56 PM, Robert Miller r...@rlmiller.org wrote: I think you can accomplish all these goals without unbloating graphs. Of course it can be done without unbloating the various graph classes. I think Sage users have gotten used to (please feel free to correct me on this, Sage users!) looking for a method via tab completion. Here are two ways to refactor code, while keeping users happy. Both approaches below rely on keeping the current interfaces for spanning tree methods, while also creating a new module called sage/graphs/spanning_tree.py(x). * Move the relevant core code to the said proposed module. The core code I'm referring to would be code that does the actual computation of spanning trees, excluding some basic sanity checks, etc. The relevant existing methods would be rewritten to call the corresponding interfaces in sage/graphs/spanning_tree.py(x). Take the case of min_spanning_tree() in sage/graphs/graph.py. We move the core code that computes minimum spanning trees into sage/graphs/spanning_tree.py(x) and improve the minimum spanning tree code in that new module. The method min_spanning_tree() would not be removed entirely, but would still retain its current interface and have some possible improvement as necessary. It's only the definition that would be changed; the rewritten definition would actually call the relevant minimum spanning tree function in sage/graphs/spanning_tree.py(x) to do the heavy duty work of computing minimum spanning trees. Furthermore, we add a new method called min_spanning_tree() to the class definition of digraphs in sage/graphs/digraph.py to mirror its counterpart in sage/graphs/graph.py. But we actually call the relevant function in sage/graphs/spanning_tree.py(x) as per the rewritten min_spanning_tree() for undirected graphs. * Do the same as in the previous approach, but add deprecation warnings to the effect that the relevant methods would be entirely removed in a future release. In both of the above approaches, code for spanning trees would be centralized in sage/graphs/spanning_tree.py(x) and hence could be advertised more clearly in the reference manual. I worry about how many features we have for graphs already which I have seen users surprised to find. Follow Guido van Rossum's precedent by declaring a moratorium on adding further methods to the class definitions of undirected and directed graphs :-) Cleaning up documentation might make more people more aware of what Sage can do, but I think moving these methods (at least in name) out of the graph classes would be a push in the other direction. See my new proposal above. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Buildbot - does not seem to get much use
On Sat, Dec 4, 2010 at 12:18 PM, Niles nil...@gmail.com wrote: On Fri, Dec 3, 2010 at 11:38 AM, Robert Bradshaw Apply foo.pyx, foo2.pyx I mean of course foo.patch, foo2.patch :). This will reset the patch list at that point, any added patches will get (semi-intellegently) appended to the list. This will help reviewers who are applying things manually as well :). This seems to be working fairly well; another issue is how to tell the buildbot that one ticket depends on another (e.g. http://trac.sagemath.org/sage_trac/ticket/10052) As far as I can tell, this will be detected if depends on URL (where URL is the url of another ticket) appears anywhere on the rss version of the ticket page -- is this right? Yep. Can the depends on... appear in the ticket description or does it have to appear in one of the comments (I can't quite tell if the description is included in the text buildbot scans)? And it looks like each depends on line appends the relevant ticket to the dependency list; is there any way to remove dependencies? Perhaps instead the dependency list should reset with each new depends on line, and (if it doesn't already) accept a list of ticket dependencies at once? That way, 3 successive comments like depends on #1 depends on #2 depends on #1, #3 would result in the patches for #1 and #3 being applied, but not the one for #2. Good point. Done. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: buildbot testing documentation
On 12/7/10 4:41 AM, Robert Bradshaw wrote: That's an interesting idea, but it's not easy to expose that information. The way it works is that a build slave requests a list of tickets, rates them according to its own internal settings (which may be different for each bot), and then starts on a ticket (notifying the server to avoid overlap). I suppose as well as a pending field list, one could add something that collects different bots ratings at different points in time and their respective speeds and does an estimate. Or you could maybe pass the work on to the slave: after sorting tickets, the slave replies with a time estimate for each ticket. The server then updates the page. The bot could then send updated estimates whenever too. In the setup for a slave, it could ask for the amount of time it takes to run testall (or compute that from a test run, or take a running average over several tickets) and use that as a multiplier. Or maybe it's just better to report the lowest rating a ticket receives from a slave, and let the user use that as a gauge for how soon the ticket would be tested. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
On 12/7/10 5:25 AM, Minh Nguyen wrote: Hi Robert, On Tue, Dec 7, 2010 at 9:56 PM, Robert Millerr...@rlmiller.org wrote: I think you can accomplish all these goals without unbloating graphs. Of course it can be done without unbloating the various graph classes. I think Sage users have gotten used to (please feel free to correct me on this, Sage users!) looking for a method via tab completion. Here are two ways to refactor code, while keeping users happy. Both approaches below rely on keeping the current interfaces for spanning tree methods, while also creating a new module called sage/graphs/spanning_tree.py(x). * Move the relevant core code to the said proposed module. The core code I'm referring to would be code that does the actual computation of spanning trees, excluding some basic sanity checks, etc. The relevant existing methods would be rewritten to call the corresponding interfaces in sage/graphs/spanning_tree.py(x). Take the case of min_spanning_tree() in sage/graphs/graph.py. We move the core code that computes minimum spanning trees into sage/graphs/spanning_tree.py(x) and improve the minimum spanning tree code in that new module. The method min_spanning_tree() would not be removed entirely, but would still retain its current interface and have some possible improvement as necessary. It's only the definition that would be changed; the rewritten definition would actually call the relevant minimum spanning tree function in sage/graphs/spanning_tree.py(x) to do the heavy duty work of computing minimum spanning trees. Furthermore, we add a new method called min_spanning_tree() to the class definition of digraphs in sage/graphs/digraph.py to mirror its counterpart in sage/graphs/graph.py. But we actually call the relevant function in sage/graphs/spanning_tree.py(x) as per the rewritten min_spanning_tree() for undirected graphs. * Do the same as in the previous approach, but add deprecation warnings to the effect that the relevant methods would be entirely removed in a future release. I worry that it is too confusing to have a min_spanning_tree function in the documentation of the spanning_tree module that is different than the min_spanning_tree method of a graph (different interface, more checks, etc.). How about an option 3: * directly import the spanning_tree.min_spanning_tree function into the graph/digraph namespaces. That way, spanning_tree.min_spanning_tree(G) is exactly the same as G.min_spanning_tree(). Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Problems with Save and Quit?
http://ask.sagemath.org/question/229/when-does-notebook-save-worksheets-persistently Has anyone else ever seen this? Hopefully the OP will say what version is being used. Anyway, this is the first time I've heard of this, but I do remember that several of our participants in the summer workshop were a little nervous about auto-save being disabled, and I know from personal experience that it can be a little hit-or-miss when Save makes a snapshot. Maybe it's time to revisit autosaves on a low-frequency basis (10 min.?). Or maybe not, but since this seemed fairly serious, I wanted to put it out there in case others had noticed something like it. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Goto Blas.
On 12/7/10 12:05 AM, Thierry Dumont wrote: The Goto Blas are now under BSD license. http://www.tacc.utexas.edu/tacc-projects/gotoblas2/ This could be a replacement for Atlas (these blas are supposed to be faster). How active is the project? The second sentence in the above page is: This product is no longer under active development by TACC, but it is being made available to the community to use, study, and extend. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Goto Blas.
On 12/7/10 12:05 AM, Thierry Dumont wrote: The Goto Blas are now under BSD license. http://www.tacc.utexas.edu/tacc-projects/gotoblas2/ This could be a replacement for Atlas (these blas are supposed to be faster). According to the developer's wikipedia page [1], Kazushige Gotō joined Microsoft's Technical Computing Group in 2010. I wonder if that's why the library appears to be abandoned to the open source community. Thanks, Jason [1] http://en.wikipedia.org/wiki/Kazushige_Goto -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
Hi Jason, On Wed, Dec 8, 2010 at 12:15 AM, Jason Grout jason-s...@creativetrax.com wrote: I worry that it is too confusing to have a min_spanning_tree function in the documentation of the spanning_tree module that is different than the min_spanning_tree method of a graph (different interface, more checks, etc.). That is nothing compared to the case where we have implemented minimum spanning tree for digraphs in sage/graphs/digraph.py. Now when someone wants to maintain the minimum spanning tree code, the maintainer would be looking into at least two different modules, namely sage/graphs/graph.py and sage/graphs/digraph.py. If an issue affects both implementations of minimum spanning trees, i.e. those in the directed and undirected cases, what is the chance of someone fixing both implementations in the same patch? The idea of centralization is that there is one place where a maintainer would go to maintain the relevant code. Scattering code for essentially similar functionality across more than one file is a recipe for more work on future maintainers. NetworkX was designed as a library and many of its implementation of graph theoretic algorithms are not written as methods of graph classes, but rather as separate functions and organized in separate modules. To me this makes the job of maintenance easier. But let's move beyond that argument as I get the impression that it has failed so far to impress anyone, just as the argument of method bloat has failed. How about an option 3: * directly import the spanning_tree.min_spanning_tree function into the graph/digraph namespaces. That way, spanning_tree.min_spanning_tree(G) is exactly the same as G.min_spanning_tree(). Here's an option that should preserve the current interface of min_spanning_tree() while also allowing one to discover that method via tab completion. Move min_spanning_tree() higher up the class hierarchy and into sage/graphs/generic_graph.py. Once moved there, leave the interface alone and proceed to clean-up that method as follows: * Handle the cases of digraphs, multigraphs, and multidigraphs. * Handle weighted and unweighted cases of the above graph types. Goodies like algorithms for randomized spanning tree constructions should go into another module like sage/graphs/trees.pyx. I feel this is really a time to declare a serious moratorium on adding new methods to any of the following modules, unless there is a good reason to do so: * sage/graphs/generic_graph.py * sage/graphs/graph.py * sage/graphs/digraph.py -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
Goodies like algorithms for randomized spanning tree constructions should go into another module like sage/graphs/trees.pyx. I feel this is really a time to declare a serious moratorium on adding new methods to any of the following modules, unless there is a good reason to do so: * sage/graphs/generic_graph.py * sage/graphs/graph.py * sage/graphs/digraph.py -1 on moratoriums. Adding restrictions for restriction sake is foolish. Yes, these files are too large. Yes, splitting off certain functionality will make them smaller. However, if someone implements a function which starts off a new area of graph theory, and they don't know where else to put it, it seems perfectly reasonable to put it in here. Especially if this is someone we're trying to rope in to more serious development. Later on when there are more functions, and it makes sense to split these off into a new file, that's a good idea and a good time to do it. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Goto Blas.
Le 07/12/2010 14:22, Jason Grout a écrit : On 12/7/10 12:05 AM, Thierry Dumont wrote: The Goto Blas are now under BSD license. http://www.tacc.utexas.edu/tacc-projects/gotoblas2/ This could be a replacement for Atlas (these blas are supposed to be faster). According to the developer's wikipedia page [1], Kazushige Gotō joined Microsoft's Technical Computing Group in 2010. I wonder if that's why the library appears to be abandoned to the open source community. Thanks, Jason [1] http://en.wikipedia.org/wiki/Kazushige_Goto According to a colleague of mine; there is a ticket to include the Goto blas in a forthcoming Debian distribution. And according to many friends doing numerics, these blas are faster than atlas blas. But may be the question, for Sage, is: how long does it takes to install Goto blas, compared to atlas ? t.d. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
I read this thread once and I will have to think about this subject again before coming up with anything interesting. One thing though : Would there be any way to ask Sphinx to produce one page per method instead of having them all on one page ? Having such a long page containing all our methods means that it is impossible, from Google, to find the description of a method containing at once a list of keywords... In its actual state, Google will often give this page as an answer to any request containing reference sage graph and anything else, because most of the terms are probably scattered through it. If there was a way to have instead a list of methods contained in graph.py, then a link toward a page describing each of them, it would finally become possible to isolate functions of interest through Google. I'll be back Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
RE: [sage-devel] Re: Goto Blas.
-Original Message- From: sage-devel@googlegroups.com on behalf of Jason Grout Sent: Wed 12/8/2010 2:19 AM To: sage-devel@googlegroups.com Subject: [sage-devel] Re: Goto Blas. On 12/7/10 12:05 AM, Thierry Dumont wrote: The Goto Blas are now under BSD license. http://www.tacc.utexas.edu/tacc-projects/gotoblas2/ This could be a replacement for Atlas (these blas are supposed to be faster). How active is the project? The second sentence in the above page is: This product is no longer under active development by TACC, but it is being made available to the community to use, study, and extend. . It is active, but there is now a gotoblas2 which is active as far as I know: http://www.tacc.utexas.edu/tacc-projects/#blas From memory gotoBlas (version 1) was compiling faster on my old machine than the latest atlas. We had to remove gotoblas-1 source from the gentoo tree because TACC didn't want us to redistribute them anymore. The next thing to check is whether it provides both cblas and f77blas. Version 1 only provided f77blas and we need cblas as well. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org winmail.dat
[sage-devel] Strange behaviour of add_edges
Hi,
I encountered a strange behaviour of the add_edges method for DiGraphs
(using SAGE 4.5.1). Perhaps this is intended behaviour, but as it
seems quiet odd to me I would like to hear the opinion of more
experienced (di)graph-users. Maybe this is a real bug...
If I define a looped, multi-edge empty digraph with
G=DiGraph({},multi_edges=True,loops=True)
I can add a couple of edges at once using
G.add_edges([[0,1],[0,1],[1,1],[0,0],[1,0],[0,1]])
this gives the correct graph (having 2 vertices and 6 edges).
Nevertheless, if I define my digraph with
G=DiGraph(multi_edges=True,loops=True)
or
G=DiGraph([],multi_edges=True,loops=True)
the same command to add edges
G.add_edges([[0,1],[0,1],[1,1],[0,0],[1,0],[0,1]])
gives a digraph on 2 vertices but with only 4 edges (the double edge
is not created).
Even stranger: If I put edge labels I can see that whenever I add more
edges afterwards an old edge gets deleted and is replaced by a new
one, but never does the graph have multi-edges.
Looking forward to an explanation of this funny behaviour.
Best
M.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
On 12/7/10 9:34 AM, Minh Nguyen wrote: Hi Jason, On Wed, Dec 8, 2010 at 12:15 AM, Jason Grout jason-s...@creativetrax.com wrote: I worry that it is too confusing to have a min_spanning_tree function in the documentation of the spanning_tree module that is different than the min_spanning_tree method of a graph (different interface, more checks, etc.). That is nothing compared to the case where we have implemented minimum spanning tree for digraphs in sage/graphs/digraph.py. Now when someone wants to maintain the minimum spanning tree code, the maintainer would be looking into at least two different modules, namely sage/graphs/graph.py and sage/graphs/digraph.py. If an issue affects both implementations of minimum spanning trees, i.e. those in the directed and undirected cases, what is the chance of someone fixing both implementations in the same patch? The idea of centralization is that there is one place where a maintainer would go to maintain the relevant code. Scattering code for essentially similar functionality across more than one file is a recipe for more work on future maintainers. NetworkX was designed as a library and many of its implementation of graph theoretic algorithms are not written as methods of graph classes, but rather as separate functions and organized in separate modules. To me this makes the job of maintenance easier. But let's move beyond that argument as I get the impression that it has failed so far to impress anyone, just as the argument of method bloat has failed. How about an option 3: * directly import the spanning_tree.min_spanning_tree function into the graph/digraph namespaces. That way, spanning_tree.min_spanning_tree(G) is exactly the same as G.min_spanning_tree(). Here's an option that should preserve the current interface of min_spanning_tree() while also allowing one to discover that method via tab completion. Move min_spanning_tree() higher up the class hierarchy and into sage/graphs/generic_graph.py. Once moved there, leave the interface alone and proceed to clean-up that method as follows: * Handle the cases of digraphs, multigraphs, and multidigraphs. * Handle weighted and unweighted cases of the above graph types. I think maybe I was too brief in my suggestion to be clear. I would favor refactoring the code out to a spanning_tree.py(x) file. My point was that your propositions seemed to indicate that the graph class methods that would call spanning_tree.min_spanning_tree would also do some additional error checking, maybe have a different interface, etc. My suggestion was to not have any additional code; put all of that error checking, etc., into the spanning_tree.min_spanning_tree function. In other words, the graph class would simply import the functions into the class namespace: class Graph: from spanning_tree import min_spanning_tree That way we get a standalone function in spanning_tree.min_spanning_tree, and we also get a convenient method for all graphs, and they are exactly the same function, have the same interface, etc. There is no duplication of code or of doctests. Of course, this import should probably be moved up to the generic graph class, like you suggest, if the function can handle digraphs too. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
RE: [sage-devel] Re: Goto Blas.
Seems like I didn't dig deep enough. So it isn't actively developed by the TACC anymore, it is given to the community to maintain and take over development. It only provides f77blas. I guess it would be possible to create a cblas interface using f2c but it is not really something anyone would want to maintain. So unless someone can suggest an alternative cblas implementation as well, gotoblas is not a viable alternative. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org winmail.dat
[sage-devel] Degrees-Radians Conversion
Hello, It seems Degree-Radian conversion doesn't exist in Sage. Of course, it can easily be performed by multiplying by pi/180 (or its reciprocal), but a function is more convenient. The Python has it in the math module, but it will not work with symbolics. Mathematica has the Degree constant, (http://reference.wolfram.com/mathematica/ref/ Degree.html), but I think degrees() and radians() functions would be better. Thoughts? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
Hi Nathann, On Wed, Dec 8, 2010 at 4:22 AM, Nathann Cohen nathann.co...@gmail.com wrote: Would there be any way to ask Sphinx to produce one page per method instead of having them all on one page ? I'm not aware of any way to get Sphinx to do what you're describing. Essentially you want something similar to how the Mathematica documentation is organized. If there was a way to have instead a list of methods contained in graph.py, then a link toward a page describing each of them, it would finally become possible to isolate functions of interest through Google. This page [1] of the Python documentation comes close to what you're describing. But each method/function is yet to be in its own page. Note that at [1] the table listing all the functions is manually maintained and not autogenerated by Sphinx. I'll be back *Theme music of the movie Terminator 2: Judgment Day playing in the background.* [1] http://docs.python.org/library/functions.html -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
Hi Jason, On Wed, Dec 8, 2010 at 10:26 AM, Jason Grout jason-s...@creativetrax.com wrote: I think maybe I was too brief in my suggestion to be clear. I would favor refactoring the code out to a spanning_tree.py(x) file. My point was that your propositions seemed to indicate that the graph class methods that would call spanning_tree.min_spanning_tree would also do some additional error checking, maybe have a different interface, etc. My suggestion was to not have any additional code; put all of that error checking, etc., into the spanning_tree.min_spanning_tree function. In other words, the graph class would simply import the functions into the class namespace: class Graph: from spanning_tree import min_spanning_tree That way we get a standalone function in spanning_tree.min_spanning_tree, and we also get a convenient method for all graphs, and they are exactly the same function, have the same interface, etc. There is no duplication of code or of doctests. Of course, this import should probably be moved up to the generic graph class, like you suggest, if the function can handle digraphs too. The above seems very reasonable to me. Documentation for spanning trees would be advertised on the top-level page for graph theory, while we refactor spanning tree code into the proposed module spanning_tree.py(x) and import min_spanning_tree() somewhere in generic_graph.py. This means that one could still discover min_spanning_tree() via tab completion (using a graph object) and also have the code for min_spanning_tree() centralized somewhere. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Strange behaviour of add_edges
Even stranger: The same happens for Graph as well. It seems constructing an empty graph or digraph with G=Graph(multiple_edges=True) or G=Graph([],multiple_edges=True) does not set the property of being a multi-graph. E.g. doing G afterwards gives the information Graph on 0 vertices instead of Multi-graph on 0 vertices Now I think it really is a bug. Is there already a ticket for this? Best M. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
On 12/7/10 8:06 PM, Minh Nguyen wrote: Hi Jason, On Wed, Dec 8, 2010 at 10:26 AM, Jason Grout jason-s...@creativetrax.com wrote: I think maybe I was too brief in my suggestion to be clear. I would favor refactoring the code out to a spanning_tree.py(x) file. My point was that your propositions seemed to indicate that the graph class methods that would call spanning_tree.min_spanning_tree would also do some additional error checking, maybe have a different interface, etc. My suggestion was to not have any additional code; put all of that error checking, etc., into the spanning_tree.min_spanning_tree function. In other words, the graph class would simply import the functions into the class namespace: class Graph: from spanning_tree import min_spanning_tree That way we get a standalone function in spanning_tree.min_spanning_tree, and we also get a convenient method for all graphs, and they are exactly the same function, have the same interface, etc. There is no duplication of code or of doctests. Of course, this import should probably be moved up to the generic graph class, like you suggest, if the function can handle digraphs too. The above seems very reasonable to me. Documentation for spanning trees would be advertised on the top-level page for graph theory, while we refactor spanning tree code into the proposed module spanning_tree.py(x) and import min_spanning_tree() somewhere in generic_graph.py. This means that one could still discover min_spanning_tree() via tab completion (using a graph object) and also have the code for min_spanning_tree() centralized somewhere. Yep. Basically, the method becomes a convenient alias to the function in the spanning_tree module. With this model, I can see one solution to the method bloat. Common algorithms/functions have aliases as methods. Extensions or uncommon functions don't have aliases as graph class methods, but live in the spanning_tree module. I'm not sure how I feel about it, but it is an idea... Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms
Hi Rob, On Wed, Dec 8, 2010 at 10:49 AM, Rob Beezer goo...@beezer.cotse.net wrote: I think it is important that a graph has hundreds of methods, since Sage can do hundreds of things to a graph. Tab-completion is great, and more robust wild-cards on tab-completion would be even better (isn't this one of Jason's favorite suggestions?). That said, not only is graph.py so big that doctesting is annoying, but in my text editor there is a noticeable lag for the syntax highlighting to catch-up when I temporarily unbalance a string or parenthesis. Extremely annoying. (Yes, I should switch to emacs, or vi, or something.) So a topical (algorithmic) decomposition of the source would be a great help. I think Jason's suggestion of importing a function into the namespace of GenericGraph is a very useful. The current interface is maintained while code we want to refactor would be centralized and would, presumably, help with long-term maintenance. In a sense, a very long-ish module could be unbloated as per Jason's suggestion while also lessening the annoyance with a programmer's text editor trying to catch up on syntax highlighting. -1 to moratoriums as well. Fewer rules, and more thoughtful decisions, guidance, discussion, and help. I can see some new very basic function for graphs that Sage does not have (not sure what that would be) that naturally belongs at a high level, so maybe graph.py is exactly where it should be. When I thought about a moratorium on adding new methods to any of the various graph class definitions, I had in mind the addition of actual method definition. It never occurred to me to use aliases via function import to get a function into the namespace of a class definition. I learnt something new today. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Strange behaviour of add_edges
Hi, On Wed, Dec 8, 2010 at 1:11 PM, mhs schraud...@math.uni-heidelberg.de wrote: Now I think it really is a bug. Is there already a ticket for this? I don't think so. Please open a ticket to track the issue you reported and ensure you provide a link to the current email thread. Thank you for your bug report. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Degrees-Radians Conversion
Sorry, I didn't know about that. I searched through Google but I got nothing... Thank you. On Dec 7, 5:35 pm, Jason Grout jason-s...@creativetrax.com wrote: On 12/7/10 6:58 PM, Eviatar wrote: Hello, It seems Degree-Radian conversion doesn't exist in Sage. Of course, it can easily be performed by multiplying by pi/180 (or its reciprocal), but a function is more convenient. The Python has it in the math module, but it will not work with symbolics. Mathematica has the Degree constant, (http://reference.wolfram.com/mathematica/ref/ Degree.html), but I think degrees() and radians() functions would be better. Thoughts? Like this? sage: a=4*units.angles.degree sage: a.convert(units.angles.radian) 1/45*pi*radian sage: deg=units.angles.degree sage: rad=units.angles.radian sage: b=4*deg sage: b.convert(rad) 1/45*pi*radian Here is rudimentary docs for the unit package:http://www.sagemath.org/doc/reference/sage/symbolic/units.html Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] telling buildbot which repo to apply to; a naming proposal
Count me as another person really excited about the automatic trac ticket test bot. It's great work. Good job, Robert! First, my proposal: we should call that bit of software patchbot, since it automatically deals with patches; the other buildbot (http://build.sagemath.org/sage/) takes tarballs and builds them. Having two completely distinct services both called buildbot is confusing. I propose patchbot. Thoughts? Second, I have two patches on a ticket (http://trac.sagemath.org/sage_trac/ticket/10440); one gets applied to the Sage library, the other to the scripts repo. How do I tell what-we-currently-call-buildbot where to apply patches? Thanks! Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
Re: [sage-devel] telling buildbot which repo to apply to; a naming proposal
On Tuesday, December 7, 2010, Dan Drake dr...@kaist.edu wrote: Count me as another person really excited about the automatic trac ticket test bot. It's great work. Good job, Robert! First, my proposal: we should call that bit of software patchbot, since it automatically deals with patches; the other buildbot (http://build.sagemath.org/sage/) takes tarballs and builds them. Having two completely distinct services both called buildbot is confusing. I propose patchbot. Thoughts? i propose tracbot Second, I have two patches on a ticket (http://trac.sagemath.org/sage_trac/ticket/10440); one gets applied to the Sage library, the other to the scripts repo. How do I tell what-we-currently-call-buildbot where to apply patches? Thanks! Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] telling buildbot which repo to apply to; a naming proposal
On Tuesday, December 7, 2010, Dan Drake dr...@kaist.edu wrote: Count me as another person really excited about the automatic trac ticket test bot. It's great work. Good job, Robert! First, my proposal: we should call that bit of software patchbot, since it automatically deals with patches; the other buildbot (http://build.sagemath.org/sage/) takes tarballs and builds them. Having two completely distinct services both called buildbot is confusing. I propose patchbot. Thoughts? i propose tracbot Second, I have two patches on a ticket (http://trac.sagemath.org/sage_trac/ticket/10440); one gets applied to the Sage library, the other to the scripts repo. How do I tell what-we-currently-call-buildbot where to apply patches? Thanks! Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] telling buildbot which repo to apply to; a naming proposal
On Tue, 07 Dec 2010 at 09:20PM -0800, William Stein wrote: On Tuesday, December 7, 2010, Dan Drake dr...@kaist.edu wrote: First, my proposal: we should call that bit of software patchbot, since it automatically deals with patches; the other buildbot (http://build.sagemath.org/sage/) takes tarballs and builds them. Having two completely distinct services both called buildbot is confusing. I propose patchbot. Thoughts? i propose tracbot That sounds fine too. Anything but two buildbots that do completely different things! Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
Re: [sage-devel] telling buildbot which repo to apply to; a naming proposal
On Tue, Dec 7, 2010 at 9:18 PM, Dan Drake dr...@kaist.edu wrote: Count me as another person really excited about the automatic trac ticket test bot. It's great work. Good job, Robert! First, my proposal: we should call that bit of software patchbot, since it automatically deals with patches; the other buildbot (http://build.sagemath.org/sage/) takes tarballs and builds them. Having two completely distinct services both called buildbot is confusing. I propose patchbot. Thoughts? I like patchbot as well, in fact that's almost what I called it the first time around. Tracbot implies that it's tied to trac, which it isn't necessarily. Second, I have two patches on a ticket (http://trac.sagemath.org/sage_trac/ticket/10440); one gets applied to the Sage library, the other to the scripts repo. How do I tell what-we-currently-call-buildbot where to apply patches? The patchbot works by creating branches so that it doesn't have to create a entirely new copy of Sage for every ticket. Of course scripts doesn't play nicely with branching, so it can't even handle this. Eventually it should be extended to handle the other repos and spkgs, but that's future work. (Note that this is yet another justification for moving the scripts repo into the main repository, even if you enjoy manually managing patches to the two distinct repositories yourself.) - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
