[sage-devel] Re: Iterators for various structures

Argh, my mail client just tricked me. Anyway: The main reason is that I see no mathematical obvious way of iterating through all vectors of the integers. The (arbitrarily) decided way in the patch seems usable in only very few cases (and it does not even contain vectors with any negative elements)

[sage-devel] Re: Iterators for various structures

Now my compilation of the patched Sage finished, and it seems that the patch doesn't even work anymore. SearchTree doesn't have a breadth_first_search_iterator; maybe that class has changed while the patch has been waiting for review? On Aug 2, 12:09 pm, "Johan S. R. Nielsen"

[sage-devel] Re: Iterators for various structures

Hi David Thanks. I thought I would start a discussion here, though, because it seems like a general issue whether or not to add iterators on such structures. Cheers, Johan On Aug 2, 12:15 pm, David Joyner wrote: > Hi Johan: > > Maybe your email got cut off somehow? > > I'm not sure what you were

[sage-devel] A scalable framework for error-correcting code functionality in Sage

As part of my newly begun Ph.D studies, I am planning to extend Sage's functionality in error correcting codes. I have already had some conversations with David Joyner about this, and we agreed that before any major work should be undertaken, a general framework of the classes and functionality sho

[sage-devel] Re: Cloning is frustratingly slow

I agree. I started developing for Sage last week and used the clone function twice before moving on to queues. Queues are not difficult to understand and the bookkeeping is rather minimal, so I think that the Developer's guide could skip clone completely. As an aside, how sophisticated are the var

[sage-devel] Re: Cloning is frustratingly slow

oc with an arbitrary build/clone. > > Doctesting only changed files is > > $ ./sage -tnew > > from the home directory for Sage, I think.  But in any case not > everything is built anew after you make a change - only the changed > files, and any files depending on them, I

[sage-devel] Re: Cloning is frustratingly slow

(just as the -b flag works, I guess)? By the way, I'm sorry if I have carried this thread somewhat off track. On Aug 3, 9:49 am, Minh Nguyen wrote: > Hi Johan, > > On Tue, Aug 3, 2010 at 5:36 PM, Johan S. R. Nielsen > > wrote: > > Why doesn't the Developer

[sage-devel] Re: Some feature requests on SAGE - Adding Engineering to the target audience

> 4. MATRIX INPUT > If the "[...]m" syntax is messing too much with Python's syntax, don't > implement it then, but I keep thinking there should be an easier way > than the one right now to input matrices. It's just not comfortable > for people who does an intensive usage of matrices. > (Another al

[sage-devel] Re: A scalable framework for error-correcting code functionality in Sage

Hi Ryan, Great to have an engineer on this as well. I'm probably more to the theoretical side of things, though I am technically an engineer :-) > Your framework sounds good to me. In fact, it's somewhat similar to > what I have done. In my case, a particular code is relatively > uninteresting,

[sage-devel] Re: Cloning is frustratingly slow

> 2.  -tnew > > Not in the developer walkthrough since I didn't know about it when I > wrote that.  Limited testing indicates it looks for changed files in > the mercurial repository that have not been commit'ed and tests > those.  It strikes me that looking for dependencies is a big job - > there

[sage-devel] Re: How does real_lazy work?

I actually think that the part of the discussion relating to inheritance and scalability is quite fundamental for the structuring of Sage. The problem is -- at its core -- that we have an object which, in object-oriented eyes, _is_ a RingElement but we want to call the computationally efficient imp

[sage-devel] Re: How does real_lazy work?

On Aug 11, 1:28 pm, koffie wrote: > Hej Johan, > > It indeed seems to be at the core of a wider problem. The core of the > problem seems that sometimes you can represent various objects in > different ways. > > - So in the coding theory example you can represent a general linear > code by a genera

[sage-devel] Re: A scalable framework for error-correcting code functionality in Sage

l. What do you say? - Johan On Aug 3, 8:03 pm, Ryan Hinton wrote: > Johan, > > Replies inline below. > > On Aug 3, 3:34 am, "Johan S. R. Nielsen" > wrote: > > > ... > > I guess that Ensembles as you describe them could be implemented > > compl

[sage-devel] Re: A scalable framework for error-correcting code functionality in Sage

l. What do you say? - Johan On Aug 3, 8:03 pm, Ryan Hinton wrote: > Johan, > > Replies inline below. > > On Aug 3, 3:34 am, "Johan S. R. Nielsen" > wrote: > > > ... > > I guess that Ensembles as you describe them could be implemented > > compl

[sage-devel] Re: A scalable framework for error-correcting code functionality in Sage

Damn you, Refresh-button! Is there a way to delete such a duplicate post? -- 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

[sage-devel] Re: A scalable framework for error-correcting code functionality in Sage

On Aug 12, 6:40 pm, Ryan Hinton wrote: > Hello, Johan. > > I'm a little confused at your restatement of my idea as well as your > description of your idea.  Let me provide some code fragments to be > concrete. > > class Code: >     def __init__(..., encode_algorithm=['alg_name', args], > decode_al

[sage-devel] Re: two polynomial questions

> >  > 1. There is no way to get a symbolic interpolated polynomial de novo > >  > without going through polynomial rings, e.g. all these steps: > >  > > >  > pts = [(1,2),(2,3),(3,2),(4,3),(5,2),(6,3)] > >  > R.=QQ[] > >  > f = R.lagrange_polynomial(pts) > >  > SR(f) > >  > Everything you're doin

[sage-devel] Re: two polynomial questions

> 2. If one has a non-symbolic polynomial currently, it won't plot with > the new plotting syntax. > > plot(f,0,5) # works, old-school Sage > plot(f,(x,0,5)) # doesn't work, new-school Sage > plot(f,x,0,5) # doesn't work, though sort of makes sense it shouldn't > since x isn't a symbolic variable n

[sage-devel] Two doctest-failures on a competely clean Sage 4.5.3 compilation

Hi everyone I downloaded the Sage 4.5.3 source, compiled everything and ran a doctest (./sage -testall) immediately afterwards. I guess everything should run smoothly, but surprisingly, there were two failures: - sage -t "devel/sage/sage/misc/explain_pickle.py" **

[sage-devel] Re: Two doctest-failures on a competely clean Sage 4.5.3 compilation

On Sep 20, 1:25 am, Mitesh Patel wrote: > On 09/18/2010 05:39 AM, Johan S. R. Nielsen wrote: > > > > > I downloaded the Sage 4.5.3 source, compiled everything and ran a > > doctest (./sage -testall) immediately afterwards. I guess everything > > should run smoothly

[sage-devel] Re: Two doctest-failures on a competely clean Sage 4.5.3 compilation

On Sep 20, 9:41 am, Mitesh Patel wrote: > I don't, unfortunately.  Does anyone have suggestions?  Both of the > failed tests appear to involve pickling. Yes. And Cython-code. And the str() function applied to weird objects. > > > The explanation is that parallel testing is unreliable. People are

[sage-devel] Re: Suggestion to provide external links in documentation.

I think this is quite a good idea as a complement to the usual topical documentation and for luring other math-software users in. The biggest problem is maintenance, I guess: I don't exactly know how much Mathematica, Maple etc. change in each version, but for the more obscure functions, there will

[sage-devel] Re: Decorators degrading documentation

Hi > I find the generic version of the function definitions less than > satisfactory. I'd guess it would be had to make Sphinx pickup the > more detailed info in these situations? I'd also guess the decorators > could maybe manipulate the docstring and inject some information based > on the argu

[sage-devel] Re: Decorators degrading documentation

First of all, sorry for the terrible word-wrapping in my previous post; it seems Google groups wraps at less than 80 characters. On Sep 23, 2:57 pm, Jason Grout wrote: > On 9/23/10 7:13 AM, Johan S. R. Nielsen wrote: > > > > > Hi > > >> I find the generic version of

[sage-devel] Re: Decorators degrading documentation

On Sep 23, 2:57 pm, Jason Grout wrote: > On 9/23/10 7:13 AM, Johan S. R. Nielsen wrote: > > > > > Hi > > >> I find the generic version of the function definitions less than > >> satisfactory.  I'd guess it would be had to make Sphinx pickup the >

[sage-devel] Re: bug wranglers

I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already

[sage-devel] Re: bug wranglers

I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already

[sage-devel] Re: Review wranglers

On Oct 22, 10:49 am, Jeroen Demeyer wrote: > On 2010-10-21 06:33, Robert Bradshaw wrote: > > > Finally, we need more automation. Refereeing code shouldn't > > have to involve downloading and applying patches and running all > > tests--that should all be done automatically (with failing tickets > >

[sage-devel] Re: Review wranglers

On Oct 22, 9:26 pm, Jason Bandlow wrote: > On 10/22/2010 12:20 PM, Robert Bradshaw wrote: > > > Given the difficulty of finding reviewers, are you arguing we > > shouldn't try to make things even easier? Yes, it's not to bad ([copy > > the url, qimport, qpush] * n, build, test, run doctests, qpop,

[sage-devel] Re: Extension of category framework: Does it make sense to open a ticket for this?

> Generalizing code for the sake of generalization and at the expense of > efficiency is probably a bad choice, especially for something so > pervasive as the category framework, but if you can show that the more > general code is necessary to do things people actually want, it > becomes worth eval

[sage-devel] Re: Regression testing

+1 to the idea of time testing doctests. I would use them all the time for regression testing and when testing improvements; not the least for my own Sage "library". It seems to me that only very rarely it would be interesting to look at other's timing tests, and so, I don't really think the extra

[sage-devel] Re: Blog Post: "How to referee Sage Trac tickets"

Very nice. Will this be put somewhere persistent where new Sage developers can be expected to find it? E.g. as a supplement to the Developer's Guide. I have one comment: In the current version, sage.misc.misc.deprecation has some steep limitations. Trac #9919 (along with #9907) fixes it so it can

[sage-devel] Re: Blog Post: "How to referee Sage Trac tickets"

On Nov 3, 8:59 am, Florent Hivert wrote: >       Hi there, > > > > On Mon, Nov 01, 2010 at 05:30:55AM -0500, Jason Grout wrote: > > On 11/1/10 12:23 AM, William Stein wrote: > > >http://sagemath.blogspot.com/2010/10/how-to-referee-sage-trac-tickets... > > > Nice.  I'll have more comments later, bu

[sage-devel] Re: "Why Sage?" Website Section

A little C-procrastination and relocation to my own site, and Google is ok: http://www.student.dtu.dk/~jsrn/whysage.jpg On Nov 12, 12:16 pm, Minh Nguyen wrote: > Hi Eviatar, > > On Fri, Nov 12, 2010 at 7:15 PM, Eviatar wrote: > > I made a quick mockup of a possible page, let me know what you th

[sage-devel] Re: "Why Sage?" Website Section

First of all, I think that such a page put at a prominent place (as the entry-page for what is now the Tour, perhaps?) will be a good selling point. You need to hook people before they have read pages of text, because otherwise most of them will already have continued on. > David Kirkby wrote > Th

[sage-devel] Re: "Why Sage?" Website Section

On Nov 13, 4:13 pm, rjf wrote: > On Nov 13, 6:32 am, "Johan S. R. Nielsen" > wrote: > > > two info boxes on this suggested "Why Sage"-page. > > > I don't think that Python is the perfect language to write mathematics > > software

[sage-devel] Re: Asymptote (vector graphics language)

On Oct 10, 10:40 am, Jason Grout wrote: > On 10/9/11 3:19 AM, Jeroen Demeyer wrote: > > > On 2011-10-08 01:36, jsymons wrote: > >> Maybe some of you, based on the experience of using it, could explain > >> better than me what are the advantages/disadvantages with respect to > >> Tachyon renderer.

[sage-devel] Representation of finite field elements

Hi all I work a lot with finite fields and polynomials over these, and the standard string representation of finite field elements as polynomials is not very convenient for me; I would much prefer to represent each non-zero element as a power of the field's generator. I am having trouble making the

[sage-devel] Re: Representation of finite field elements

On Dec 12, 11:35 am, javier wrote: > Hi Johan, > > do you have the "typeset" box checked in your notebook? > If so, then things are displayed using the latex method > instead of the repr one. > > Cheers, > Javier OF COURSE! Thanks for telling me. I would have thought that I had enough Sage-experi

[sage-devel] Re: Representation of finite field elements

Wow, this opened up a can of worms I hadn't expected, but reading your comments, I really agree. > When I was working on similar issues for printing real numbers (i.e., > whether to truncate digits, etc.), Carl Witty brought up a very good > point. Printing representation options should be global

[sage-devel] Re: When is a test not a valid test?

> On the topic of verifying tests, I think internal consistency checks > are much better, both pedagogically and for verifiability, than > external checks against other (perhaps inaccessible) systems. For > example, the statement above that checks a power series against its > definition and propert

[sage-devel] Re: buildbot testing documentation

Wow, this is really cool! Great work! Also, great plans for ways to let people run their own buildbots, hooked up to the central server. With customisation so ones own patches will be prioritised whenever needed, hopefully a lot of people will feel that it's really _easier_ for them to have a build

[sage-devel] Re: graph theory: refactor implementation of spanning tree algorithms

On Dec 11, 10:56 pm, Nathann Cohen wrote: > Hello everybody !!! > > My question on sphinx-dev was finally answered : it sounds possible to > have one page per method ! :-) > > http://groups.google.com/group/sphinx-dev/browse_thread/thread/41a2fc... > > Nathann Nice! However, what exactly should w

[sage-devel] Re: Updating the Developer's Walk-Through

On Feb 21, 2:27 am, Rob Beezer wrote: > I'm inclined to update the "Walking Through the Development Process" > section of the Developer Guide. > > I've had some feedback (in-person) and have seen a few thoughtful > comments in various places in sage-devel.  Other than mentioning new > features (li

[sage-devel] Re: Documentation of prcedures with decorator

I don't know what influence there is from Cython, but for general python-functions, decorators need to decorate their return functions with @sage_wraps (see e.g. sage.plots.contour_plot.contour_plot) to get the correct doc-strings. Setting these could be done manually in the decorator, but it is th

[sage-devel] Re: profiling Sage startup

On Feb 23, 11:03 pm, Jason Grout wrote: > On 2/23/11 3:56 PM, Robert Bradshaw wrote: > > > > > On Wed, Feb 23, 2011 at 1:47 PM, Jason Grout > >  wrote: > >> On 2/23/11 3:06 PM, Robert Bradshaw wrote: > > >>> On Wed, Feb 23, 2011 at 11:34 AM, William Stein     > >>> wrote: > > On Wed, Feb 23,

[sage-devel] Re: profiling Sage startup

On Mar 1, 10:13 am, Robert Bradshaw wrote: > On Tue, Mar 1, 2011 at 12:48 AM, Johan S. R. Nielsen > > > > wrote: > > On Feb 23, 11:03 pm, Jason Grout wrote: > >> On 2/23/11 3:56 PM, Robert Bradshaw wrote: > > >> > On Wed, Feb 23, 2011 at 1:47 PM, Jas

[sage-devel] Re: profiling Sage startup

On Mar 1, 1:56 pm, luisfe wrote: > > No, the lazy_import object keeps wrapping the original object, but > when accessing the lazy_import object it imports the real object in > the namespace. So, if the lazy_import has not been referenced by > another object then it will be collected as garbage. I

[sage-devel] Re: profiling Sage startup

On Mar 1, 1:56 pm, luisfe wrote: > > Yes, it is not used much. Ideally, the way of improving sage > startuptime would be: > > 1.- On first execution by a user, create a pickle of lazy_import of > the global names and save it in the .sage directory. This should not > be slower than current startup.

[sage-devel] Re: Proposal - Add notes of "verification" as comments to doctests

On Mar 14, 10:58 am, Volker Braun wrote: > On Monday, March 14, 2011 6:13:54 AM UTC, Dr. David Kirkby wrote: > > > 1) A doctest should have a comment by it, referencing the trac ticket where > > the > > test was added. In other words, just simply "Trac #1234" if the test was > > added > > on ticke

[sage-devel] Fixed: Decorators ruining documentation

Hi everyone Can someone please review ticket #9976; its patch has been there for ~6 months now. It fixes a problem with decorators and Sphinx: as it is now, most decorated functions will get a generic signature in the Sphinx documentation. Notable examples include most of the plot commands, e.g.

[sage-devel] Re: MATLAB: viable alternative...?

. In time, I think this would make people migrate to Sage because of expense, ideology and functionality. Cheers, Johan S. R. Nielsen -- 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 F

[sage-devel] Re: GSoC "New decoding error-correcting codes algorithm for Sage"

iscussions. Best, Johan S. R. Nielsen On Thursday, May 30, 2013 5:48:38 PM UTC+2, Verónica Suaste wrote: > > Hi all, > > I'm Verónica, an undergraduate math student. I'm glad to share with you > the fact that my project for GSoC 2013 has been selected. The main idea o

[sage-devel] 2-year project with full-time software developer for improving coding theory in Sage

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 grou

[sage-devel] 2-year project with full-time software developer for improving coding theory in Sage

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 grou

Re: [sage-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage

Thanks for the feedback everyone! I'll try to comment on some of the things mentioned. 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

Re: [sage-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage

Repost from sage-coding-theory, by Daniel Augot: This is great news! Is there any plan to implement semaphore codes in the > near future (see the book by Jean Berstel > , Dominique > Perrin

Re: [sage-devel] A new book on Sage, for high school students in Poland

Congratulations on your book! It looks beautiful and well-motivating. I don't read any polish, so I can't judge contents, but I can tell you that the "browsability value" of the book is very high, which is important when you're judging which book to take home from the book store or library :-) Beau

Re: [sage-devel] reviewing prevented code written by a cat from getting into Sage

Cats on the keyboard are dangerous! My cat once ran over my keyboard while I was in Vim. The result: deleted all contents of the file, saved AND nuked the undo buffer! Thank goodness for version control... kcrisman writes: > I usually catch those before committing. I still don’t know how one of

[sage-devel] subs semantic

Hi, +1, that seems to make sense, and it's a good idea to have both semantics available. Note that there are also complicated mixes: sage: R. = RR[] sage: Zxy = PolynomialRing(ZZ,'x,y,z') sage: xx,yy,zz = Zxy.gens() sage: (xx+yy).subs(x=x).parent() Multivariate Polynomial Ring in x, y, z over Re

[sage-devel] The coefficients() method of a MultivariatePowerSeriesRing is unreasonably slow

The call to f.coefficients() run the following lines (self = f): tmp = {} for j in self._bg_value.coefficients(): for m in j.monomials(): tmp[self.parent(m)]=j.monomial_coefficient(self.parent()._poly_ring(m)) I may be missing something, but it seems that instead of the inner loop, on

[sage-devel] Re: Trac - internal error

Same thing here, #19251. Johan david.lu...@inria.fr writes: > Hello, > > Same thing with some of tickets: #19653, #19666, #19722, #19422 and #19623 > > David > > Le vendredi 15 janvier 2016 15:37:58 UTC+1, Clemens Heuberger a écrit : >> >> Trac detected an internal error: >> >> OSError: [Errno

[sage-devel] Should a // b really be the same as a / b in fields?

The behaviour for ZZ--QQ--RR decided in that other thread are taking quotients over the sub-ring ZZ. More specifically: if a,b are in ZZ, QQ or RR then it was decided that a % b should implicitly satisfy: a == (a//b) * b + a%b and a//b in ZZ and a%b has norm smaller than b (norm as in euclidea

[sage-devel] Re: Sage GSOC 2016

How does it work with Sage's application to GSoC and what are the relevant deadlines? Also, in what period should the project be conducted? I have an idea for a project I would like to mentor, but I have to be sure that I'm available in the period. Best, Johan Samuel Lelièvre writes: > Mentors

[sage-devel] Re: Matrix unicode output

> > help() with parameters to show longer help? (And smaller default than > help() now prints.) help() could definitely be more helpful on concepts. For instance, the typesetting we're talking about here could appear if you typed `help("terminal")` or something. There could be a list of predefine

[sage-devel] promotional video

Cool! You have a good narration voice :-) > You made this to promote SageMathCloud. Don't call it a SageMath > promotional video. Oh man, not *that* discussion again... Best, Johan William Stein writes: > We made a SageMath promotional video this weekend > > https://youtu.be/AEKOjac9obk

Re: [sage-devel] Query about SageMath for GSOC

> For example: We have an equation (2+3*(8/2)) and when I solve this > equation in SageMath it gives the exact answer i.e 14. However, it's > really interesting to imagine if Sage prints all the steps that how > they solve the above equation to find its answer like first it print > this (2+3*4) by

Re: [sage-devel] Query about SageMath for GSOC

#x27;re motivated about contributing to Sage though! Best, Johan Amritpal Singh writes: > On Wednesday, March 9, 2016 at 2:24:22 PM UTC+5:30, Johan S. R. Nielsen > wrote: >> Hi Amritpal, > >> A related, and mathematically quite important feature, is that of >> "cert

Re: [sage-devel] Query about SageMath for GSOC

ots of attention from prospective students. Best, Johan Amritpal Singh writes: > On Thu, Mar 10, 2016 at 6:09 PM, Johan S. R. Nielsen > wrote: >> Sorry, apart from answering the odd email on this list, I'm not going to >> guide such a project. I'm not particularly inter

Re: [sage-devel] Request to extend the binomial function by the reflection formula

Sage seems to use the definition from Concrete Mathematics by Graham, Knuth and Patashnik: binomial(r, k) = r*(r-1)*...*(r-k+1)/(k * (k-1) *...* 1) if k >= 0 and r any real number, and binomial(r, k) = 0 if k < 0 That gives e.g. sage: binomial(-4, 5) -56 Though Peter's suggestion seems

Re: [sage-devel] Request to extend the binomial function by the reflection formula

Overall, I think the proposed change makes sense in the long run, and Peter presents a good case. But there are some dangers. Foremost, Clemens argues that a change will potentially brake user code: while this is true, I think it should be overruled for the long benefits, if another behaviour is m

Re: [sage-devel] What to global namespace?

> As an example: IMO KleinFourGroup() should be groups.KleinFour() just like > we have graphs.PetersenGraph(). I completely agree. For coding theory, we have also started to put everything into catalogues codes. and channels., and the functions and constructors in global namespace are slowly gett

Re: [sage-devel] What to global namespace?

Jori Mäntysalo writes: > > For graphs we have > > from sage.graphs.generators.smallgraphs import * > > and > > from sage.graphs.generators.platonic_solids import * > > and it seems unnecessary but not that harmful to have two set to import. > > * * * > > So, we could have also something like > >

Re: [sage-devel] Re: how we develop sage

> But there is a way to make code work in Sage as upgrades happen - making it > a part of Sage :-) > Thus I don't buy this "future-proof" statement (well, of course, Sage may > fold if sufficient number of right people get hit by a bus - but the same > is true for Magma) It has something to do

Re: [sage-devel] Re: how we develop sage

> I don't agree with Dima that putting their code into Sage is what > researchers should do, no matter what. > > I do care a lot about my research code, and I know some of it has no place > inside Sage. Maintaining it outside of Sage is not just carelessness or > laziness, it's a design choice.

Re: [sage-devel] Re: Integration of function and it's simplified version yields different results

> Why so offensive? Don't worry - rjf is always spectacularly offensive. His tone is not representative of how the rest of us write on this list. Thanks for taking the time to start this discussion (on which I have no technical input). Best, Johan -- You received this message because you are s

[sage-devel] Heavy-computation @property in Matrix class

Hi I came across the following in sage/matrix/matrix2.pyx:14367: @property def I(self): r""" Returns the inverse of the matrix, if it exists. """ return ~self Basically, I don't understand why this def should be a property, and it seems to me to b

[sage-devel] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

> I agree those things are a problem. I think I know why it was done: > > Transposition of a matrix is often written as M^T . It's difficult to > support that syntax, so using M.T seems like a nice approximation. Once you > have that, doing the same for conjugate and conjugate-transpose is a small

[sage-devel] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

Attempting to change the subject to focus on the suggestion to deprecate the properties. -- 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...@go

Re: [sage-devel] Re: Heavy-computation @property in Matrix class

> well, deprecating ".T", etc, just because it breaks an emacs mode, looks like > a huge overkill, especially from the vim camp :-\) Ah, you misunderstand me. I'm not arguing against the sugar due to the Emacs mode - I'm arguing against the sugar because it's Bad For Consistency. > Besides, ".T"

[sage-devel] Re: Heavy-computation @property in Matrix class

> Would it be feasible to let properties return some kind of "Undefined" > or "NotImplemented" or "None", rather than throwing an exception? That would side-step the entire purpose of exceptions: catching errors fast and where they occur. This is extremely bad for debugging, and yet another source

[sage-devel] Re: Heavy-computation @property in Matrix class

> One advantage of properties over methods is that they autocomplete I don't understand? Tab-completion covers both methods and properties in all IDEs I'm aware of. Best, Johan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

[sage-devel] Re: Heavy-computation @property in Matrix class

VulK writes: > sage: B = matrix() > sage: B.T.roo > > and get > > sage: B.T.rook_vector I see, didn't know that. Of course, the reason that IDEs follow this is the underlying convention that a) Properties are blazingly fast to compute. b) Properties don't throw exceptions. Neither of which are

[sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

In the previous discussion concerning properties on Matrix, there seemed to be consensus that Matrix.I was a problem. More generally, only little defence of the general use of properties in the public API was given. Therefore, I suggest that we phase out *all* uses of properties in the public API.

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

> Wouldn't you have to get rid of all public attributes as well when doing > this? > Or why should > sage: x.some_attribute > work and > sage: x.some_attribute_by_at_property > be forbidden? My impression is that public attributes generally are frowned upon, in Sage as in many other projec

Re: [sage-devel] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

> Consistency is a definitive plus, as well as not impeding > introspection. So I would tend to agree to officially phase out > properties from the public API. > > There is one use case for properties in the public API though which I > would like to bring up, namely "glorified methods". > ... Yes,

Re: [sage-devel] Rank Metric Codes in Sage

Welcome to the Sage community, Arpit! I'm sure this GSoC project will become a very nice addition to Sage :-) Best, Johan -- 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 em

[sage-devel] Deprecate the use of properties in all public API

William Stein writes: > Unless the above messed up dichotomy is fixed in every possible way > people might use Sage interactively, I'm personally 100% against using > properties for objects users interact with at the top level. They > have only snuck in in a couple of places because I wasn't payin

[sage-devel] Deprecate the use of properties in all public API

Michael Orlitzky writes: > I have a matrix m... how come, > > * m.rank gives me bullshit > * m.rank() works > * m.T() crashes > * m.T works? This is in my mind the most compelling reason to phase out properties in Sage. I think Erik makes many good points, but ultimately I think consistenc

[sage-devel] Re: How to implement conversion between LaurentPolynomial and Symbolic rings?

>> sage: R. = PolynomialRing(QQ) >> sage: (x + 1/x).parent() >> Fraction Field of Univariate Polynomial Ring in x over Rational Field > > Is it really expected by all users (I see a sum, > not a fraction)? I thought algebraists don't touch > symbolics with a long stick... I would certainly yes! If

[sage-devel] Certain warning messages are issued many times

Many warning messages are currently being issued every time the offending code is being run, instead of only the first time: sage: C = codes.RandomLinearCode(4, 2, GF(2)) sage: C.decode(C.ambient_space().random_element()) /home/jsrn/local/sage/sage-6.3/src/bin/sage-ipython:1: Deprecati

[sage-devel] Re: Certain warning messages are issued many times

On Thursday, May 12, 2016 at 12:44:31 PM UTC+2, Johan S. R. Nielsen wrote: > > A related warning is that of @experimental. It seems that if one uses > @experimental in the __init__ of a class, then a FutureWarning message > is issued every time an element of that class is construct

[sage-devel] content of polynomials

>3. Make `content` always return an element, create a method ` >content_ideal` to return an ideal, and implement `content` only over >PIDs. I vote 3 as well. It limits confusion when coming from other systems while not really being confusing for new-CAS users. > A. What kind of depre

[sage-devel] Re: Should we close all tickets with milestone "sage-duplicate/invalid/wontfix"?

>>>But maybe for examplehttp://trac.sagemath.org/ticket/8170could be justclosed? >> >> Was that a typo for another ticket? > > No. It is a good example of what Jeroen said, I think. A reasonable > suggestion made 6 years ago, no comments at all after that, no comments > telling how this should b

Re: [sage-devel] Why do we discard (repeatedly) all warning filters?

> At the moment any time a deprecation warning is issued all warning filters > are thrown away: > https://github.com/sagemath/sage/blob/master/src/sage/misc/superseded.py#L138 > which means that Python functionality for tuning warnings is completely > useless. Why??? If the point is to change the

[sage-devel] print to python3

> Breaking "print a" will cause a truly epic level of pain to our users for > no real gain... So much so that probably no matter what is decided here I > would fork sage to add handling this to the pre-processor for sage on SMC. > I'm here from endless users (eg each year at the sage booth) about

[sage-devel] Re: print to python3

> Let me try to summarize. We seem to more or less agree that we should not > repeatedly break the code of all users of sage. To avoid that, it would be > better to switch completely to python3 in just one major change. And then > there will be something like the "last py2 release" and the "firs

[sage-devel] Renaming generic curve classes

Hi Grayson, I'm really looking forward to your GSoC on curves! > Currently, the plane curve classes do not inherit from the space curve > ... > It seems that it would be a lot clearer to have a different naming > scheme, such as having ProjectiveCurve_generic be called > ProjectiveCurve_plane, a

[sage-devel] Users can permanently modify GF(5).list()

Hi sage-devel We just came across the following bizarre behaviour: sage: F = GF(5) sage: F.list() [0, 1, 2, 3, 4] sage: F.list().remove(0) sage: F.list() [1, 2, 3, 4] sage: GF(5).list() [1, 2, 3, 4] Which means that the user has just forever destroyed GF(5) in this Sage session! This currently c

Re: [sage-devel] Users can permanently modify GF(5).list()

On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote: > > No. Better use a immutable data structure instead of a list. > Oh yeah, that's much better. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group a

  1   2   >