Re: [sage-devel] What should be the present working directory for sage -notebook=ipython ?
On Mon, Oct 13, 2014 at 06:25:01AM -0700, Sébastien Labbé wrote: Time to vote. What do you prefer as default directory for the ipython notebook? - pwd - DOT_SAGE/notebooks_ipython/ pwd without hesitation! That's one of my main gripe about the sage notebook. And I had trouble with this just this morning in my class. 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-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: (fwd from sage-support) A mathematical mistake in root_lattice_realizations.py
Hi Dinakar, On Mon, Oct 13, 2014 at 11:57:25PM -0700, Travis Scrimshaw wrote: I wrote that part of the code and was assuming the user would be checking if a root is real or imaginary. However I'm definitely for adding this feature and having a method `is_root`. We can check if an element in the root space is a root in a finite root system by (the perhaps somewhat dumb) checking if it is in the (finite) set of all roots, which Sage can generate as you're probably aware. Also what's there for is_short/long/imaginary_root follows Prop 5.10 in Kac, so we could probably combine all 3 into a simple is_root for finite, affine, and ([1]to be implemented #15974) hyperbolic types. Please create a ticket on trac and cc me (tscrim) and we can fix things up. Thanks for your feedback and interest in contributing! Having a is_root method would indeed be of general interest, and like Travis I am not sure how to implement it efficiently. I would be in favor of checking, in is_real_root, that the input is indeed a root, but *only* if doing so does not add a serious overhead (that is checking is_root does not cost not much more than checking is_real_root). Otherwise, I would do like for is_positive_root or to_simple_root: namely adding in the specifications that the input *should* be a root. Alternatively, we could add a check method, and is_root would only be checked if check=True. 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-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] 2-year project with full-time software developer for improving coding theory in Sage
Hi sage-devel This is to announce and get some feedback on the start of a Sage software-development project. This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for hiring a full-time software developer for two years to work on extending the coding theory functionality in Sage. We have hired David Lucas, who just started 1st October, and is already working on getting an overview of coding theory and Sage. The aim of the project is to implement a much larger basis of functionality for coding theory which is flexible, modular and useful for the many facets of coding theory: algebra, combinatorics, engineering, cryptography, etc. The current status is that there are many useful functions from a mostly combinatorical viewpoint. From an algebraic viewpoint, though one can construct the generator matrix of e.g. a Reed--Solomon code, there is no specific class or functionality which investigates such a code from its algebraic perspective (e.g. a fast decoder). We would like to implement such things and many other. We would like to discuss all details with the community, and we also hope that this project will get a ball rolling, reinvigorating the interest in Sage for the coding theory community. Most of these discussions are better taken on sage-coding-theory, since they will be quite specific to the field. It is my impression that such a full-time developer for Sage is a rare thing, and we have been thinking on how best to proceed and communicate goals and progress. Of course, all code will go through the Trac and thus indirectly progress is tracked. However, since this will be longer-running thing, our plan is to make a dedicated (small) web page with a road map as well as an overview of already written functionality (which is furthermore annotated as already included in Sage or not). This is not a blog, but just an overview for new-comers, people interested in the development, or people who previously rejected Sage for coding theory use but who might now reconsider it. One thing we have been thinking about how to handle well is development in parallel with the ticket/review system. Since David is working full-time, he will be producing a lot of code, and there will all the time be a significant backlog in the review process. Our fear is that juggling a cobweb of ticket dependencies might become clumsy if not handled well. Do people have ideas for handling this well? We expect that within 2-3 months, David has made the main refactorings of the existing coding theory functionality, and extended it in various ways to exercise the new structure. This will most likely be more or less internal (not on Trac). After this, he will start posting these changes to Trac, while in parallel continuing to develop more new functionality. Regards, Johan S. R. Nielsen -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: KASH and polynomials of degree 22 and 23
KASH/KANT hasn't been maintained since about 2008 or something like that. I think you are pretty unlikely to get a response from their email address. However, I think I hear the voice of one of the former maintainers going into his office just down the hall from me. I'll ask him. If he says anything interesting I'll report back. Bill. On Wednesday, 15 October 2014 06:35:45 UTC+2, Jori Mantysalo wrote: See http://trac.sagemath.org/ticket/13810 . Can somebody confirm that KASH really bugs with polynomials of degree 22 and 23? For me it works only up to 21 in three different Linux-machine. I did ask about this from mail address found on KANT/KASH www-page, but got no response. And in any case there is a bug: Sage says automatically restarting but do not. (See! I can also ask something not related to posets! :=) ) -- Jori Mäntysalo -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage
That is great news AFAIK, there is still some code from last year's GSoC which is not merged, so maybe it is a good oportunity to retake that (ticket #14973) El miércoles, 15 de octubre de 2014 17:22:40 UTC+2, Johan S. R. Nielsen escribió: Hi sage-devel This is to announce and get some feedback on the start of a Sage software-development project. This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for hiring a full-time software developer for two years to work on extending the coding theory functionality in Sage. We have hired David Lucas, who just started 1st October, and is already working on getting an overview of coding theory and Sage. The aim of the project is to implement a much larger basis of functionality for coding theory which is flexible, modular and useful for the many facets of coding theory: algebra, combinatorics, engineering, cryptography, etc. The current status is that there are many useful functions from a mostly combinatorical viewpoint. From an algebraic viewpoint, though one can construct the generator matrix of e.g. a Reed--Solomon code, there is no specific class or functionality which investigates such a code from its algebraic perspective (e.g. a fast decoder). We would like to implement such things and many other. We would like to discuss all details with the community, and we also hope that this project will get a ball rolling, reinvigorating the interest in Sage for the coding theory community. Most of these discussions are better taken on sage-coding-theory, since they will be quite specific to the field. It is my impression that such a full-time developer for Sage is a rare thing, and we have been thinking on how best to proceed and communicate goals and progress. Of course, all code will go through the Trac and thus indirectly progress is tracked. However, since this will be longer-running thing, our plan is to make a dedicated (small) web page with a road map as well as an overview of already written functionality (which is furthermore annotated as already included in Sage or not). This is not a blog, but just an overview for new-comers, people interested in the development, or people who previously rejected Sage for coding theory use but who might now reconsider it. One thing we have been thinking about how to handle well is development in parallel with the ticket/review system. Since David is working full-time, he will be producing a lot of code, and there will all the time be a significant backlog in the review process. Our fear is that juggling a cobweb of ticket dependencies might become clumsy if not handled well. Do people have ideas for handling this well? We expect that within 2-3 months, David has made the main refactorings of the existing coding theory functionality, and extended it in various ways to exercise the new structure. This will most likely be more or less internal (not on Trac). After this, he will start posting these changes to Trac, while in parallel continuing to develop more new functionality. Regards, Johan S. R. Nielsen -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Code fails on SECOND attempt only... please help!
In the midst reviewing ticket 16986, my reviewer came up with the following example that fails: R.z=PolynomialRing(QQ) K.w=NumberField(z^3+2) R.t=PolynomialRing(K) L.v=K.extension(t^2+t+1) P.x,y=ProjectiveSpace(L,1) H=End(P) f=H([x^3-2*y^3,v*y^3]) f.rational_preimages(P([0,1])) However, when I run it on my machine, I get it to run with no problems, returning [(-w*v : 1), (-w : 1), (w*v + w : 1)] BUT, when I run it a second time, making no changes, I get the following error: Traceback (click to the left of this block for traceback) ... TypeError: unable to convert 1/2*w^2*v to a rational After restarting my notebook, I receive the first answer, and upon running it a second time, I get the second error. I've tried running on other copies of Sage, and the same thing happens, it will work the first time, but fail the second time. On further investigation, using the .dumps function, it seems that f is changing every time we compile. However, it seems that it only ever changes the very first time. What I mean to say by that is that when I dump f after running it the first time it will be different than when I dump f after running it a second time. From the second time on, dumping f will always return the same string. This is weird, what is the underlying mechanics causing this, and how can we trace it more explicitly. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Code fails on SECOND attempt only... please help!
I guess caching is causing that. Creating ProjectiveSpace twice with the same input creates two projective spaces that are equal (P==Q) but not identical (P is not Q). Caching will look at == so if you compute something on the second projective space then you might get back something from the first projective space. Haven't looked at the ticket, though. On Wednesday, October 15, 2014 5:49:50 PM UTC+1, Joao Alberto de Faria wrote: In the midst reviewing ticket 16986, my reviewer came up with the following example that fails: R.z=PolynomialRing(QQ) K.w=NumberField(z^3+2) R.t=PolynomialRing(K) L.v=K.extension(t^2+t+1) P.x,y=ProjectiveSpace(L,1) H=End(P) f=H([x^3-2*y^3,v*y^3]) f.rational_preimages(P([0,1])) However, when I run it on my machine, I get it to run with no problems, returning [(-w*v : 1), (-w : 1), (w*v + w : 1)] BUT, when I run it a second time, making no changes, I get the following error: Traceback (click to the left of this block for traceback) ... TypeError: unable to convert 1/2*w^2*v to a rational After restarting my notebook, I receive the first answer, and upon running it a second time, I get the second error. I've tried running on other copies of Sage, and the same thing happens, it will work the first time, but fail the second time. On further investigation, using the .dumps function, it seems that f is changing every time we compile. However, it seems that it only ever changes the very first time. What I mean to say by that is that when I dump f after running it the first time it will be different than when I dump f after running it a second time. From the second time on, dumping f will always return the same string. This is weird, what is the underlying mechanics causing this, and how can we trace it more explicitly. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage
On Wed, Oct 15, 2014 at 12:47 PM, mmarco mma...@unizar.es wrote: That is great news Agreed. great news! AFAIK, there is still some code from last year's GSoC which is not merged, so maybe it is a good oportunity to retake that (ticket #14973) El miércoles, 15 de octubre de 2014 17:22:40 UTC+2, Johan S. R. Nielsen escribió: Hi sage-devel This is to announce and get some feedback on the start of a Sage software-development project. This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for hiring a full-time software developer for two years to work on extending the coding theory functionality in Sage. We have hired David Lucas, who just started 1st October, and is already working on getting an overview of coding theory and Sage. The aim of the project is to implement a much larger basis of functionality for coding theory which is flexible, modular and useful for the many facets of coding theory: algebra, combinatorics, engineering, cryptography, etc. The current status is that there are many useful functions from a mostly combinatorical viewpoint. From an algebraic viewpoint, though one can construct the generator matrix of e.g. a Reed--Solomon code, there is no specific class or functionality which investigates such a code from its algebraic perspective (e.g. a fast decoder). We would like to implement such things and many other. We would like to discuss all details with the community, and we also hope that this project will get a ball rolling, reinvigorating the interest in Sage for the coding theory community. Most of these discussions are better taken on sage-coding-theory, since they will be quite specific to the field. It is my impression that such a full-time developer for Sage is a rare thing, and we have been thinking on how best to proceed and communicate goals and progress. Of course, all code will go through the Trac and thus indirectly progress is tracked. However, since this will be longer-running thing, our plan is to make a dedicated (small) web page with a road map as well as an overview of already written functionality (which is furthermore annotated as already included in Sage or not). This is not a blog, but just an overview for new-comers, people interested in the development, or people who previously rejected Sage for coding theory use but who might now reconsider it. One thing we have been thinking about how to handle well is development in parallel with the ticket/review system. Since David is working full-time, he will be producing a lot of code, and there will all the time be a significant backlog in the review process. Our fear is that juggling a cobweb of ticket dependencies might become clumsy if not handled well. Do people have ideas for handling this well? We expect that within 2-3 months, David has made the main refactorings of the existing coding theory functionality, and extended it in various ways to exercise the new structure. This will most likely be more or less internal (not on Trac). After this, he will start posting these changes to Trac, while in parallel continuing to develop more new functionality. Regards, Johan S. R. Nielsen -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage
Hello ! Agreed. great news! Indeed. I do not know if what you have in mind about coding theory somehow overlaps with combinatorial designs (in particular orthogonal arrays/BIBD :-P) but it would be nice to shake those areas of Sage anyway. Of course, all code will go through the Trac and thus indirectly progress is tracked. However, since this will be longer-running thing, our plan is to make a dedicated (small) web page with a road map as well as an overview of already written functionality (which is furthermore annotated as already included in Sage or not). This is not a blog, but just an overview for new-comers, people interested in the development, or people who previously rejected Sage for coding theory use but who might now reconsider it. One thing we have been thinking about how to handle well is development in parallel with the ticket/review system. Since David is working full-time, he will be producing a lot of code, and there will all the time be a significant backlog in the review process. Our fear is that juggling a cobweb of ticket dependencies might become clumsy if not handled well. Do people have ideas for handling this well? Make many small tickets. The best way to not have many dependencies is to have your code integrated into the successive beta versions of Sage, this way your 'current code' will never be too far from the develop version. Whatever happens, please, don't come some day with 3Mb of changes. Respect our development process: write tickets, get them reviewed. Writing code takes much longer than reviewing it, so if the three of you can work by reviewing the code he writes everything will run smoothly. Also, each commit message should begin with trac #number:, otherwise it is a mess to know which commits belong to which ticket when you have many dependencies. We expect that within 2-3 months, David has made the main refactorings of the existing coding theory functionality, and extended it in various ways to exercise the new structure. This will most likely be more or less internal (not on Trac). After this, he will start posting these changes to Trac, while in parallel continuing to develop more new functionality. Once more: please, don't try to shortcut the review process. Play it fair. Don't develop everything in your office only to come back later expecting us to merge everything at once without reviewing it. Please create tickets, please discuss the implementations on the tickets, please review everything. Sage's review process makes things slower, but if you are 3+1 to be interested in this project you have the manpower (and the will) to do this properly. I will be glad to help whenever I can. It sure is a a good news. Nathann -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage
About dependencies (again): Working with Vincent on Combinatorial Designs (many tickets between beta releases) taught us that it is better to 'artificially' order all tickets linearly. Each ticket should have a successor and a predecessor, and they should all be linearly ordered. It is tempting to let some branches be independent, but if for some reason you find out later that they still interact somehow it will create a *LOT* of mess if you already have tickets based on those two branches. Nathann -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage
On Wed, Oct 15, 2014 at 07:58:53PM +0200, Nathann Cohen wrote: About dependencies (again): Working with Vincent on Combinatorial Designs (many tickets between beta releases) taught us that it is better to 'artificially' order all tickets linearly. Each ticket should have a successor and a predecessor, and they should all be linearly ordered. It is tempting to let some branches be independent, but if for some reason you find out later that they still interact somehow it will create a *LOT* of mess if you already have tickets based on those two branches. On en revient finalement à la bonne vieille pile de patchs :-) Bon, ok, avec quand même de la bien meilleure technologie pour rebaser! Bonne nuit! 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-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage
This is great news! Is there any plan to implement semaphore codes in the near future (see the book by Jean Berstel http://www.goodreads.com/author/show/399140.Jean_Berstel, Dominique Perrin http://www.goodreads.com/author/show/926712.Dominique_Perrin, Christophe Reutenauer http://www.goodreads.com/author/show/399139.Christophe_Reutenauer on Codes and Automata)? This would be super useful! Anne On Wednesday, October 15, 2014 8:22:40 AM UTC-7, Johan S. R. Nielsen wrote: Hi sage-devel This is to announce and get some feedback on the start of a Sage software-development project. This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for hiring a full-time software developer for two years to work on extending the coding theory functionality in Sage. We have hired David Lucas, who just started 1st October, and is already working on getting an overview of coding theory and Sage. The aim of the project is to implement a much larger basis of functionality for coding theory which is flexible, modular and useful for the many facets of coding theory: algebra, combinatorics, engineering, cryptography, etc. The current status is that there are many useful functions from a mostly combinatorical viewpoint. From an algebraic viewpoint, though one can construct the generator matrix of e.g. a Reed--Solomon code, there is no specific class or functionality which investigates such a code from its algebraic perspective (e.g. a fast decoder). We would like to implement such things and many other. We would like to discuss all details with the community, and we also hope that this project will get a ball rolling, reinvigorating the interest in Sage for the coding theory community. Most of these discussions are better taken on sage-coding-theory, since they will be quite specific to the field. It is my impression that such a full-time developer for Sage is a rare thing, and we have been thinking on how best to proceed and communicate goals and progress. Of course, all code will go through the Trac and thus indirectly progress is tracked. However, since this will be longer-running thing, our plan is to make a dedicated (small) web page with a road map as well as an overview of already written functionality (which is furthermore annotated as already included in Sage or not). This is not a blog, but just an overview for new-comers, people interested in the development, or people who previously rejected Sage for coding theory use but who might now reconsider it. One thing we have been thinking about how to handle well is development in parallel with the ticket/review system. Since David is working full-time, he will be producing a lot of code, and there will all the time be a significant backlog in the review process. Our fear is that juggling a cobweb of ticket dependencies might become clumsy if not handled well. Do people have ideas for handling this well? We expect that within 2-3 months, David has made the main refactorings of the existing coding theory functionality, and extended it in various ways to exercise the new structure. This will most likely be more or less internal (not on Trac). After this, he will start posting these changes to Trac, while in parallel continuing to develop more new functionality. Regards, Johan S. R. Nielsen -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
