Re: [sage-devel] Proposal: remove SAGE_UPGRADING

On 2014-09-29 22:58, Volker Braun wrote: I propose to remove the SAGE_UPGRADING variable and make it act like it would be always "yes" (instead of "no", which is the current default). Right now, we sabotage "make" to not rebuild dependencies of rebuilt packages. So you don't have to wait long for

[sage-devel] Re: Proposal: remove SAGE_UPGRADING

On Tuesday, September 30, 2014 12:53:48 AM UTC+1, John H Palmieri wrote: > > +1, and maybe also consider moving $(PKGCONF) to "base" and removing the > explicit dependencies on it, so that minor changes to this package don't > force rebuilding essentially all of Sage. (That's how "base" works, ri

[sage-devel] Re: Proposal: remove SAGE_UPGRADING

On Monday, September 29, 2014 1:58:43 PM UTC-7, Volker Braun wrote: > > I propose to remove the SAGE_UPGRADING variable and make it act like it > would be always "yes" (instead of "no", which is the current default). > Right now, we sabotage "make" to not rebuild dependencies of rebuilt > pack

Re: [sage-devel] Re: Proposal: remove SAGE_UPGRADING

On 30/09/2014, at 12:02, William A Stein wrote: > On Mon, Sep 29, 2014 at 3:01 PM, Dima Pasechnik wrote: >> On 2014-09-29, Volker Braun wrote: >>> I propose to remove the SAGE_UPGRADING variable and make it act like it >>> would be always "yes" (instead of "no", which is the current default).

Re: [sage-devel] Re: Proposal: remove SAGE_UPGRADING

On Mon, Sep 29, 2014 at 3:01 PM, Dima Pasechnik wrote: > On 2014-09-29, Volker Braun wrote: >> I propose to remove the SAGE_UPGRADING variable and make it act like it >> would be always "yes" (instead of "no", which is the current default). >> Right now, we sabotage "make" to not rebuild dependen

[sage-devel] Re: Proposal: remove SAGE_UPGRADING

On 2014-09-29, Volker Braun wrote: > I propose to remove the SAGE_UPGRADING variable and make it act like it > would be always "yes" (instead of "no", which is the current default). > Right now, we sabotage "make" to not rebuild dependencies of rebuilt > packages. So you don't have to wait long

[sage-devel] Re: SageManifolds v0.6: first graphical capabilities for charts

PS: one may find some details about the implementation of SageManifolds in the slides of a presentation I gave three weeks ago at a conference in Spain. In particular the slide #25 shows the structures involved in the storage of tensor

[sage-devel] Proposal: remove SAGE_UPGRADING

I propose to remove the SAGE_UPGRADING variable and make it act like it would be always "yes" (instead of "no", which is the current default). Right now, we sabotage "make" to not rebuild dependencies of rebuilt packages. So you don't have to wait long for your broken Sage installation. The onl

[sage-devel] Re: sagetex documentation not where it should be

On Mon, 29 Sep 2014 at 11:27AM -0700, kcrisman wrote: > I'm preparing a brief talk on using SageTeX, and discovering that the > tutorial seems to be incorrect. See http://trac.sagemath.org/ticket/17068 I pushed a fix. Review needed. :) > Also, this also means that at least some of the informat

Re: [sage-devel] Re: Defining Polynomial Rings with same variable name

How about a compromise: if the user uses the command-line-only shortcut forms like R.=... or R=QQ[x,y] which go through preparsing, then it is checked that the names provided are distinct (from each other only). But in library code this is not checked, or at least no more than at present where th

[sage-devel] Re: sagetex documentation not where it should be

Sorry, the title is inaccurate - the documentation IS where it should be, but the tutorial is wrong. My apologies. Hi all, > > I'm preparing a brief talk on using SageTeX, and discovering that the > tutorial seems to be incorrect. See > http://trac.sagemath.org/ticket/17068 > > I'm emailing

[sage-devel] sagetex documentation not where it should be

Hi all, I'm preparing a brief talk on using SageTeX, and discovering that the tutorial seems to be incorrect. See http://trac.sagemath.org/ticket/17068 I'm emailing sage-devel because a) I don't have time to fix this but b) I think this is pretty critical, since people are often asking about

[sage-devel] Re: Google Research blog post mentioning Sage and SageMathCloud...

On Monday, September 29, 2014 12:32:19 PM UTC-4, William wrote: > > > http://googleresearch.blogspot.com/2014/09/collaborative-mathematics-with.html > > > -- > Nice. Though one would think that the blog poster would have mentioned his own early involvement in Sage :-) -- You received thi

[sage-devel] Re: Defining Polynomial Rings with same variable name

On Monday, September 29, 2014 7:44:35 AM UTC-7, Volker Braun wrote: > > We talked about this once, afair it is the same in Magma. > Except that in magma the print name of variables has no semantic value and can be changed at any point. > Really, there is no reason for forbidding it > Well, th

[sage-devel] Re: Defining Polynomial Rings with same variable name

In fact, I think that this feature is explicitely allowed and that, as long as you stay within the sage library, code should not break for having a ring with repeated variables. However, I agree that it is weird. Funny example: sage: K=QQ['x,y,y,x'] sage: sum(K.gens()) x + y + y + x sage: _(x=

[sage-devel] Google Research blog post mentioning Sage and SageMathCloud...

http://googleresearch.blogspot.com/2014/09/collaborative-mathematics-with.html -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group an

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

Dear list, Let's for sanity's sake suppose that == among all vertex labels of FinitePosets is an equivalence relation. Let's moreover suppose that hashing respects this equivalence relation. Then the problem seems to be that in the unique representation (an_integer_labelled_hasse_diagram, list_o

[sage-devel] Re: Defining Polynomial Rings with same variable name

However not enforcing distinct variable names breaks the following method: sage: R. = QQ[] sage: R.gens_dict() {'x': x} (which is what I'd use to implement algebra_generators). So one must be somewhat careful. Best, Travis On Monday, September 29, 2014 7:44:35 AM UTC-7, Volker Braun wrote: >

[sage-devel] Re: Defining Polynomial Rings with same variable name

We talked about this once, afair it is the same in Magma. Really, there is no reason for forbidding it. And deep inside your own code you might want to add a variable to a polynomial ring given to you by the user, and it would be inconvenient to have to pick a letter that is not yet present in

[sage-devel] Defining Polynomial Rings with same variable name

While reviewing some code, I realized that the following is currently allowed: P. = PolynomialRing(QQ,6) P Multivariate Polynomial Ring in x, x, x, x, x, x over Rational Field I believe that an object should not be allowed to have repeat instances of the same variable names. I don't get any act

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

> Obligatory: You mean equality of the set of vertex labels or equality of the > vertex labels up to permutation? I mean that I suppose that for any vertex x among my n vertices there is only ONE vertex y such that x==y is True. Now if we could talk about the question I asked it would be very coo

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

On Monday, September 29, 2014 2:19:25 PM UTC+1, Nathann Cohen wrote: > > No problem there, == is well defined. > Obligatory: You mean equality of the set of vertex labels or equality of the vertex labels up to permutation? sage: GF(5)(1) == 11 True sage: Set([GF(5)(1)]) == Set([11]) False

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

Yo ! > If < is not a total order then you need to define the permutation with > respect to a chosen set of vertex labels (another UniqueRepresentation for > vertex label set). Though frankly I'd be happy to require that vertex labels > are sortable if distinct. We have a lot of code in Graph that

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

On Monday, September 29, 2014 1:50:32 PM UTC+1, Nathann Cohen wrote: > > > Then there is an easy normal form, sort the vertex labels and permute > the > > Hasse diagram accordingly. > <= is always a total order ? > If they are all distinct then <= is the same as < If < is not a total order th

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

> Then there is an easy normal form, sort the vertex labels and permute the > Hasse diagram accordingly. <= is always a total order ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving email

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

On Monday, September 29, 2014 1:16:36 PM UTC+1, Nathann Cohen wrote: > > > The obvious answer: if the vertex labels are not all distinct > They are all distinct. > Then there is an easy normal form, sort the vertex labels and permute the Hasse diagram accordingly. -- You received this messa

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

> Well, then can you find other places where this design is an issue? (What I > mean by that, is giving wrong answer) I don't know how to produce it differently, for in many places the elements are "sorted" in this way: list({a_dictionary_whose_keys_are_the_vertices}) > Otherwise, maybe it can be

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

Well, then can you find other places where this design is an issue? (What I mean by that, is giving wrong answer) Otherwise, maybe it can be fixed on the relabel function level (once again, I don't know how it works). And yes, I agree Sage should should say True on the example you give. 2014-09-2

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

> But from what I see, the problem comes specifically from the > relabel method, My design problem is asbtract well-defined. > can you reproduce an equality error without using relabel? No, is that a problem ? Nathann -- You received this message because you are subscribed to the Google Group

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

I don't know much about the design of Posets, I guess Travis knows much more than I do. But from what I see, the problem comes specifically from the relabel method, can you reproduce an equality error without using relabel? This, for instance, is working as it should: sage: p1 = Poset(([1,2,3],[(

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

> The obvious answer: if the vertex labels are not all distinct They are all distinct. > The answer if you care about fast computation: Define == as strict identity > of pair(Hasse diagram, labels), not isomorphism up to permutation. Provide a > separate is_isomorphic() method for the latter.

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

The obvious answer: if the vertex labels are not all distinct then you need to replace the (single) Hasse diagram with the equivalence class of Hasse diagrams under the vertex permutations fixing the labels. Either find some normal form of Hasse diagram under the permutation action, or use froz

[sage-devel] Tell me how the design of the Poset class is not flawed

Hello everybody, Here is the current design of the Poset class: def Poset(an_acyclic_labelled_digraph): ... FinitePoset(UniqueRepresentation): def __init__(self, an_integer_labelled_hasse_diagram, list_of_vertex_labels): ... As FinitePoset are UniqueRepresentation, two posets p1,

[sage-devel] Please review ipython notebook

Now would be a good time to review the IPython notebook: http://trac.sagemath.org/ticket/16996 There is clearly more to be done to make the integration perfect, and we could also always wait for the next IPython version. But a bird in the hand is worth two in the bush... -- You received this

[sage-devel] SageManifolds v0.6: first graphical capabilities for charts

Hi, We have just released a new version of SageManifolds at http://sagemanifolds.obspm.fr/ The main new features are 1/ The *graphical output* of charts: 2D or 3D "grid" representation of a given chart in terms of another chart (possibly on a different manifold, via some immersion); examples

Re: [sage-devel] Best way to store a database?

Oh, and i forgot to mention: some of the invariants are only well defined up to multiplication by a unit. That means that quering for the knots with a given invariant means not only to check for the ones with identical value in that field, but to make a (potentially costly) comparison one by one

Re: [sage-devel] Best way to store a database?

The way that the info is stored in the downloadable knot altas is explained here: http://katlas.math.toronto.edu/wiki/The_Take_Home_Database I don't know about the snappy databse. But i agree it would be cool to have it. Right now it goes beyond the scope of the knotr/link module, but maybein