Re: [sage-devel] Re: spkgs assumed for doctesting but not default installed

Hi, I've now recompiled Sage after rolling back llvm-libs to 3.7.1-1 (was 3.8.0.1). That fixed the GLIBCXX errors spewing out of ar and ranlib, but it didn't fix the problem: my newly compiled version of Sage is still born without most of the default spkgs, including sympy, jmol, palp, cremona

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

I've created #20904 to deprecate the Matrix.I property which is ready for review. This seemed to be the only case that most people agreed was bad. There remains Matrix.T and Matrix.H as well as a handful of other public API properties scattered randomly across Sage. Best, Johan -- You receiv

[sage-devel] Call to `__cmp__` method on `list` in `Factorization` class fails

> /sage/local/lib/python2.7/site-packages/sage/structure/factorization.pyc > in __cmp__(self, other) > 426 c = cmp(self.__unit, other.__unit) > 427 if c: return c > --> 428 return list.__cmp__(self, other) > 429 > 430 d

Re: [sage-devel] Global namespace and independent python packages

> from sage.misc.misc import inject_variable > from mytest.test import atest > inject_variable('atest',atest) > > *Question*: do people think that it is reasonable for a package to do this? I would also say "No". The reason is that if that is what the user wanted, he could just have done "from myt

Re: [sage-devel] Global namespace and independent python packages

Hi Andrew, To import into the global namespace use sage: from mytest import * As a package author, you shouldn't force the user to load the functions into the global namespace. However, it might be possible by getting hold of the globals() object or something. If you want to import the package

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

Volker Braun writes: > I've said it before: list() should always return a tuple. Yes I know its > called list, but its just an English thing that verb and noun can't be > distinguished. Certainly no excuse to cache mutable data structures. This is now #20743. Since I am currently unable to compi

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

Sage: Parent. I'm sure Parent.list() is used for all sorts of stuff everywhere in Sage. I'm seriously surprised this bug hasn't shown up before... Best, Johan Johan S. R. Nielsen writes: > On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote: >> >>

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

[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

[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] 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] 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

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] 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

[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: 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] 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: 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] 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] 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

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

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] 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

[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.

[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] 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

> 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

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] 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

[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] 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

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

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: 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] 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] 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] 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] 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] 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] 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

> 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

[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

[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] 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] 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: 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] 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] 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

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

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

[sage-devel] Re: About abbreviation in function names

> I tried that in emacs as I had not heard of it and it sounded useful > -- but (in a python file) got an error message about requiring a > python process to be running. I'm just referring to (dabbrev-expand), bound to M-/ on a clean Emacs in most major modes. There's "dynamic expansion using infe

[sage-devel] Re: About abbreviation in function names

> rings.integral_domains.DVR() > instead of > rings.integral_domains.DiscreteValuationRing() I would definitely prefer DiscreteValuationRing() here. Mathematics is pretty verbosely written, and I think Sage should reflect how most mathematics is written. I'm in a research field with strong inter

[sage-devel] Re: What are catalogs (groups., matrices.) supposed to contain exactly?

> >> To sum up, I would put a class/function in the respective catalogue if: >> 1) It's "polished" as in nicely callable by the user in a Sage session. >> 2) It's reasonably useful for people interested in the field of the >> catalogue. >> 3) It's not imported in the global name space. > > I

Re: [sage-devel] Re: What are catalogs (groups., matrices.) supposed to contain exactly?

Hi, In catalogues, I would only put classes and functions that are directly useful for users and should be easily accessible. It that way, it is exactly like exporting into the global name space, except that the catalogue's classes and functions are strongly related, and possibly more specialised

Re: [sage-devel] Re: questions about option: inplace vs copy

Basically +1 for Volker's suggestion. Vincent's suggestion on the semantics of "copy" in constructors seem very dangerous: even if my construction of MyNewObject works today, a seemingly unrelated change to either the caller code or MyNewObject tomorrow could completely break things in highly surpr

Re: [sage-devel] [sage-cloud] slowness with sums of ideals in ZZ[a, b]

Hi, The test takes about 92ms on my laptop (Sage 6.8.rc1, core i7-4600 @ 2.10 GHz). So if it's a Sage 6.7-thing, it's fixed again :-) Johan William Stein writes: > On Fri, Jul 31, 2015 at 8:36 AM, Pierre wrote: >> Hi, >> >> I have asked a version of this question here: >> >> https://groups.g

Re: [sage-devel] Sage-enabled textbook for Abstract Algebra

Hi Rob, This is really very nice! I took my first steps in algebra reading Tom Judson's book on my own, quite some years ago. Already back then, math and programming were both major interests of mine. Having Tom Judson's book containing intriguing Sage examples and challenges makes it, it seems t

Re: [sage-devel] Spam on AskSage

The top post on ask.sagemath.org is spam again :-( Johan Thierry writes: > in think we are in a semi-stable state now, all spam is removed, let's see > if some spam comes again. > > Ciao, > Thierry > > > > On Fri, Jul 17, 2015 at 10:04:07AM +0200, Thierry wrote: >> Hi, >> >> actually, this star

Re: [sage-devel] Functions returning sub-structure

Jori Mäntysalo writes: > > I understood. But when do user have an object of class lattice and he or > she wants to check that it is a lattice? This could easily happen in a function that accepts any poset but can do clever stuff when the input happens to be a lattice. Say I have a ProductPoset

Re: [sage-devel] Functions returning sub-structure

Jori Mäntysalo writes: > >>> At least for now we don't have parameter like >>> trust_me_i_know_what_i_am_doing=True for posets or lattices. > >> Such a parameter would make lots of sense, I think. > > I have thinked about it. It needs some more thinking - how much should be > trusted? But at leas

Re: [sage-devel] Functions returning sub-structure

Jori Mäntysalo writes: > At least for now we don't have parameter like > trust_me_i_know_what_i_am_doing=True for posets or lattices. Such a parameter would make lots of sense, I think. > This can be > seen for example with C500=Posets.ChainPoset(500), and after that even > C500.join(100,200)

Re: [sage-devel] Functions returning sub-structure

I think that the default of returning a sublattice makes most sense by far. In case the speed difference is very significant (why would this be the case?), one could add an optional argument to the function to just return a list. Could be named "as_list = False", I guess. Johan Jori Mäntysalo wr

[sage-devel] Re: Jobs involving SageMath

+1. Such a page is very nice to have, and even nicer to link to from the main web page. The wiki, unfortunately, as a "marketing" page is not very pretty (not at all as pretty as the job offer page for the OpenDreamKit positions, for instance). I added some information on the coding theory proj

Re: [sage-devel] What is the parent() of a vector from a subspace?

On Wednesday, June 3, 2015 at 11:02:42 PM UTC+2, David Roe wrote: > > > For a vector space V over an inexact field, the statement that a vector v > belongs to a particular subspace W cannot be checked by examining an > approximation to v in V. For example, (2 + O(3^50), 4 + O(3^50)) may or > m

[sage-devel] What is the parent() of a vector from a subspace?

What is the sensible notion of parent() for a vector that I drew out of a vector subspace? For instance, what should be printed by the following lines? VS = (QQ^3).subspace([ (1, 1 ,1) ]) v = VS.an_element() print v.parent() One possibility is that QQ^3 should be printed. Alternatively, and the

Re: [sage-devel] Full-time Sage developer position opening at Université Paris-Sud for Fall 2015

Awesome news. Congratulations on the project! On Tuesday, June 2, 2015 at 12:30:47 AM UTC+2, William wrote: > > > This is a preliminary announcement for a full time Sage developer >> position > > > ... the first such position ever! :-) > > > No... The coding theory in Sage project has been runn

Re: [sage-devel] Re: Vector weirdness: to be or not to be immutable

Thanks for the clarifications, Vincent. On Wednesday, May 27, 2015 at 10:36:31 PM UTC+2, vdelecroix wrote: > What I suggesteded is to modify the code of vector subspace in such way > that the elements have parent the ambient space and not the subspace. > Which is precisely related to the end of

[sage-devel] Re: Vector weirdness: to be or not to be immutable

> The behavior is bad but I would not call it a bug. You modified wrongly > the vector. I disagree: from a user-point of view, a superficially perfectly reasonable sequence of steps were taken, at the end of which Sage prints a result which is mathematically incorrect, without any error or war

[sage-devel] Vector weirdness: to be or not to be immutable

Hi Sage-devel We just crashed our heads against a bug in our code due to extremely weird semantics of Sage. Consider the following code which creates a sub-space C of the four-dimensional vector space over the binary field, and then modifies a *copy* of a vector from the subspace: F = GF(2) VS

Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

On Saturday, February 21, 2015 at 3:42:28 AM UTC+1, Michael Orlitzky wrote: > > On 02/20/2015 11:02 AM, kcrisman wrote: > > > >> > >> I no longer use sage for my day-to-day work, but when I was and I had > to > >> e.g. give a presentation, it was infuriating to find sage broken AGAIN > >> >

[sage-devel] Fwd: Coding Theory development project. Request-for-comments: New code family and encoder/decoder structu

Hi sage-devel, An update from our coding theory development project. On Friday, February 20, 2015 at 6:24:01 PM UTC+1, Johan S. R. Nielsen wrote: > > Hello everyone, > > As we announced previously ( > https://groups.google.com/forum/#!topic/sage-devel/pBmeknQcyZM), we > star

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-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

[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

[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] 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: 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] 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: 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] 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] 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: 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] 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: 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, 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 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: 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: 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: 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: 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: 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: "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: "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

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: 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: 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: 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: 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: 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,

  1   2   >