Re: [sage-devel] Re: About recmpilations caused by Git

On 2014-11-18 23:15, Andrew wrote: That is, the manual states that the recommended route is to use sage -br unless you are modifying packages. The manual is technically correct but can easily be misinterpreted. The problem is that switching branches often *does* modify packages. In some cases

Re: [sage-devel] Re: Code of Conduct

On Nov 18, 2014 6:44 PM, "kcrisman" wrote: > > Commenting on a good point even though this is abandoned: > >> >> > the top 12 all time list of contributors to Sage, in order, are: >> > >> > [a list of 12 dudes] >> > >> >> In the event of a gender-polarizing conflict, this committee will not >> be

Re: [sage-devel] Maple versus Mathematica

> > > Problems arise when thinking about more complicated mathematical >> objects. I >> > don't know if I simply lack the appropriate Mathematica knowledge, but >> years >> > ago, when I implemented matroids in Mathematica, a matroid was simply a >> list >> > with 6 elements (groundset, repr

Re: [sage-devel] Re: Code of Conduct

Commenting on a good point even though this is abandoned: > > the top 12 all time list of contributors to Sage, in order, are: > > > > [a list of 12 dudes] > > > > In the event of a gender-polarizing conflict, this committee will not > be seen as unbiased. In order to increase minority re

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 6:51 PM, Bill Page wrote: > On 18 November 2014 17:40, Ondřej Čertík wrote: >> >> In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) / >> d conjugate(z). The Df(z) / Dz is the complex derivative taking in >> direction theta (where it could be theta=0). Giv

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 17:40, Ondřej Čertík wrote: > > In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) / > d conjugate(z). The Df(z) / Dz is the complex derivative taking in > direction theta (where it could be theta=0). Given the chain rule, as > I derived above using chain rules

[sage-devel] Bug in abs(I*x).diff(x)

Hi, With Sage 6.3, I am getting: sage: abs(x).diff(x) x/abs(x) sage: abs(I*x).diff(x) -x/abs(I*x) But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x) must be the same. But in the first case we get x/abs(x), and in the second we got -x/abs(x). In SymPy, the answer is: -

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 3:14 PM, Tom Boothby wrote: > On Tue, Nov 18, 2014 at 10:36 AM, William Stein wrote: > >> Given the potentially political nature of such a choice, one >> possibility is to do something apolitical, and select based on >> ownership. In particular, based on lines of code cont

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 10:36 AM, William Stein wrote: > Given the potentially political nature of such a choice, one > possibility is to do something apolitical, and select based on > ownership. In particular, based on lines of code contributed to Sage, > which is an (imperfect!) but non-politic

Re: [sage-devel] Maple versus Mathematica

On Tue, Nov 18, 2014 at 2:37 PM, Stefan wrote: > Problems arise when thinking about more complicated mathematical objects. I > don't know if I simply lack the appropriate Mathematica knowledge, but years > ago, when I implemented matroids in Mathematica, a matroid was simply a list > with 6 elemen

Re: [sage-devel] Maple versus Mathematica

On Tue, Nov 18, 2014 at 11:37 PM, Stefan wrote: > Problems arise when thinking about more complicated mathematical objects. This is also my main argument ... The core point is, that Python allows you to define higher-level data-types, which are some combination of data structures and convey a sem

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 2:50 PM, Bill Page wrote: > On 18 November 2014 15:19, Ondřej Čertík wrote: >> On Tue, Nov 18, 2014 at 12:14 PM, Bill Page >> wrote: >>> >>> abs(x).diff(x) >>> >>> would return the symbolic expression >>> >>> conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i

Re: [sage-devel] Re: About recmpilations caused by Git

On Tue, Nov 18, 2014 at 2:15 PM, Andrew wrote: > >> > I've gone back to sage -b. >> Please don't, or at the very least don't ever report a bug or failing >> doctest without doing "make" first. > > > I am confused by Jeroen's comment. According to the sage 6.4 developers > guide: > > Rebuilding Sag

Re: [sage-devel] Maple versus Mathematica

Problems arise when thinking about more complicated mathematical objects. I don't know if I simply lack the appropriate Mathematica knowledge, but years ago, when I implemented matroids in Mathematica, a matroid was simply a list with 6 elements (groundset, representation matrix, and I forget wh

Re: [sage-devel] Maple versus Mathematica

On Tue, Nov 18, 2014 at 2:17 PM, Dan Drake wrote: > On Tue, 18 Nov 2014 at 01:34PM -0800, William Stein wrote: >> When arguing for Maple's language over the Mathematica language, they >> say "Functional programs are often opaque; most people, even >> experienced programmers, find functional-style

Re: [sage-devel] Maple versus Mathematica

On Tue, 18 Nov 2014 at 01:34PM -0800, William Stein wrote: > When arguing for Maple's language over the Mathematica language, they > say "Functional programs are often opaque; most people, even > experienced programmers, find functional-style programs to be > significantly harder to write, read, a

Re: [sage-devel] Re: About recmpilations caused by Git

> > I've gone back to sage -b. > Please don't, or at the very least don't ever report a bug or failing > doctest without doing "make" first. > I am confused by Jeroen's comment. According to the sage 6.4 developers guide

[sage-devel] Re: Maple versus Mathematica

Writing such a comparison for all 4 packages sounds like a huge task, but it could really pay off. Your episode does ring a bell, it reminds me of the MS-RSL license. This is maybe the same case and is only there to help you to make your code compatible with their product,that's all. http://ref

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 10:29 PM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > but count me out. As far as I can see, this idea is already abandoned anyway. Still, we could do this list of by self nomination and see if this leads to anything. We could call this the "community management team

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 15:19, Ondřej Čertík wrote: > On Tue, Nov 18, 2014 at 12:14 PM, Bill Page > wrote: >> >> abs(x).diff(x) >> >> would return the symbolic expression >> >> conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta} > > I think you made a mistake, the correct expressio

[sage-devel] Re: inconsistent behavior with multivariate polynomial rings: what to do?

Sounds good to me. See http://trac.sagemath.org/ticket/17366. John On Tuesday, November 18, 2014 10:42:15 AM UTC-8, Volker Braun wrote: > > Yes, DWIM and convert the argument to the ring if it is not already there. > > > > On Tuesday, November 18, 2014 6:24:12 PM UTC, John H Palmieri wrote: >>

[sage-devel] Maple versus Mathematica

See this interesting document: http://www.maplesoft.com/products/maple/compare/HowMapleComparestoMathematica.pdf It would be valuable to our users (and potential users) if we had a similar document which explains and *argues* for why we believe our approach to mathematical software is better

Re: [sage-devel] Re: Code of Conduct

On 18 Nov 2014 18:36, "William Stein" wrote: > the top 12 all time list of contributors to Sage, in order, are: > > - William Stein > - Mike Hansen > - Volker Braun > - Jereon Demeyer > - Nathann Cohen > - Robert Bradshaw > - Robert Miller > - Simon King > - John Palmieri > -

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 1:19 PM, Ondřej Čertík wrote: > On Tue, Nov 18, 2014 at 12:14 PM, Bill Page > wrote: >> On 18 November 2014 13:41, Ondřej Čertík wrote: >>> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page >>> wrote: ... Have you had a chance to consider the issue of the chain-rul

Re: [sage-devel] Octave interface broken

Note that if you want to fix in your current 6.3, creating folder is not helpful (you already figured that out because of permission). sed -i "s:script_subdirectory='user':script_subdirectory=None:" \ src/sage/interfaces/octave.py will do the job. Francois On Tue, 18 Nov 2014 13:

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 12:14 PM, Bill Page wrote: > On 18 November 2014 13:41, Ondřej Čertík wrote: >> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page >> wrote: >>> ... >>> Have you had a chance to consider the issue of the chain-rule yet? >> >> Yes. Very straightforward, as I suggested in my last

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 8:36 PM, Harald Schilly wrote: > This is the result for the last year looking at the result again, I think it sorts by number of commits, not lines. one could tweak the number of top authors (default is 20) to get all of them in … so don't take this output seriously. --

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 14:14, Bill Page wrote: > On 18 November 2014 13:41, Ondřej Čertík wrote: >> On Tue, Nov 18, 2014 at 11:08 AM, Bill Page >> wrote: >>> ... >>> Have you had a chance to consider the issue of the chain-rule yet? >> >> Yes. Very straightforward, as I suggested in my last email.

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 11:33 AM, Anne Schilling wrote: > Not everybody who contributes through trac seems to have an account on github. > So there are lots of contributors missing! It would be fun to have somebody produce a proper list directly from the git commit history. However, I think Volk

Re: [sage-devel] Re: Code of Conduct

On Tuesday, November 18, 2014 7:37:21 PM UTC+1, William wrote: > Here is I think a concrete, apolitical proposal. > > Calculating stakeholders by core contribution is certainly possible. My only contribution would be, that this sage-abuse mailing list is read-only for all others, not hidden a

Re: [sage-devel] Re: Code of Conduct

On 11/18/14 11:07 AM, William Stein wrote: > On Tue, Nov 18, 2014 at 11:05 AM, Anne Schilling > wrote: >> On 11/18/14 10:36 AM, William Stein wrote: >>> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling >>> wrote: On 11/18/14 7:55 AM, Harald Schilly wrote: > > On Monday, November 17

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 13:41, Ondřej Čertík wrote: > On Tue, Nov 18, 2014 at 11:08 AM, Bill Page > wrote: >> ... >> Have you had a chance to consider the issue of the chain-rule yet? > > Yes. Very straightforward, as I suggested in my last email. Just start with: > > D f / D z = df/dz + df/d conjug

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 11:05 AM, Anne Schilling wrote: > On 11/18/14 10:36 AM, William Stein wrote: >> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling >> wrote: >>> On 11/18/14 7:55 AM, Harald Schilly wrote: On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote:

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 10:55 AM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > 2014-11-18 11:36 UTC-07:00, William Stein : >> On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling >> wrote: >>> On 11/18/14 7:55 AM, Harald Schilly wrote: On Monday, November 17, 2014 3:26:18 PM UTC+1,

Re: [sage-devel] Re: Code of Conduct

On 11/18/14 10:36 AM, William Stein wrote: > On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling > wrote: >> On 11/18/14 7:55 AM, Harald Schilly wrote: >>> >>> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote: >>> >>> What if instead of a "code of conduct" there was a "community >>

Re: [sage-devel] Re: Code of Conduct

2014-11-18 11:36 UTC−07:00, William Stein : > On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling > wrote: >> On 11/18/14 7:55 AM, Harald Schilly wrote: >>> >>> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote: >>> >>> What if instead of a "code of conduct" there was a "community >>>

[sage-devel] Re: inconsistent behavior with multivariate polynomial rings: what to do?

Yes, DWIM and convert the argument to the ring if it is not already there. On Tuesday, November 18, 2014 6:24:12 PM UTC, John H Palmieri wrote: > > From #17205: > > sage: x, y = ZZ['x','y'].gens() > sage: GF(1091)['x','y'].random_element().degree(x) > 2 > sage: GF(3037000453)['x','y'].random_el

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 11:08 AM, Bill Page wrote: > On 18 November 2014 12:29, Ondřej Čertík wrote: >> On Tue, Nov 18, 2014 at 9:28 AM, David Roe wrote: >>> ... >>> Because derivative is not just used in the context of functions of a >>> complex variable (whether they are analytic or not). Pro

Re: [sage-devel] Re: Code of Conduct

On Tue, Nov 18, 2014 at 10:01 AM, Anne Schilling wrote: > On 11/18/14 7:55 AM, Harald Schilly wrote: >> >> On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote: >> >> What if instead of a "code of conduct" there was a "community >> expectations" SHORT document that just say what we e

[sage-devel] inconsistent behavior with multivariate polynomial rings: what to do?

>From #17205: sage: x, y = ZZ['x','y'].gens() sage: GF(1091)['x','y'].random_element().degree(x) 2 sage: GF(3037000453)['x','y'].random_element().degree(x) ... TypeError: x must be one of the generators of the parent. I don't think the behavior should be different the polynomial rings over GF(

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 12:29, Ondřej Čertík wrote: > On Tue, Nov 18, 2014 at 9:28 AM, David Roe wrote: >> ... >> Because derivative is not just used in the context of functions of a >> complex variable (whether they are analytic or not). Probably more >> than 90% of Sage users don't know any comple

Re: [sage-devel] Re: Code of Conduct

On 11/18/14 7:55 AM, Harald Schilly wrote: > > On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote: > > What if instead of a "code of conduct" there was a "community > expectations" SHORT document that just say what we expect? > > > I'm a little bit late to this thread, but I've

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 9:28 AM, David Roe wrote: > On Tue, Nov 18, 2014 at 8:05 AM, Bill Page wrote: >> On 18 November 2014 09:02, David Roe wrote: >>> On Tue, Nov 18, 2014 at 5:57 AM, Bill Page >>> wrote: > I think you are overly focused on trying to define a derivative that >

Re: [sage-devel] Code of Conduct

On Saturday, November 15, 2014 2:10:04 PM UTC-8, P Purkayastha wrote: > Yes. Typically, they ban the user for a period of time. The violations are > dealt with on a case-by-case basis. It seems quite a few requests (code of > conduct violations, and otherwise) have piled up in > http://forums.g

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 8:05 AM, Bill Page wrote: > On 18 November 2014 09:02, David Roe wrote: >> On Tue, Nov 18, 2014 at 5:57 AM, Bill Page >> wrote: >>> >>> > I think you are overly focused on trying to define a derivative that >>> > reduces to the conventional derivative of non-analytic fun

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 09:02, David Roe wrote: > On Tue, Nov 18, 2014 at 5:57 AM, Bill Page wrote: >> >> > I think you are overly focused on trying to define a derivative that >> > reduces to the conventional derivative of non-analytic functions >> > over the reals. >> >> I've just been casually fol

Re: [sage-devel] Re: Code of Conduct

On Monday, November 17, 2014 3:26:18 PM UTC+1, kcrisman wrote: > > What if instead of a "code of conduct" there was a "community > expectations" SHORT document that just say what we expect? > I'm a little bit late to this thread, but I've read all the mails. This "expectations" document sounds

Re: [sage-devel] Bug in abs(I*x).diff(x)

> > > I think you are overly focused on trying to define a derivative that > > reduces to the conventional derivative of non-analytic functions over > > the reals. > > I've just been casually following this conversation, but I think it's > important that the derivative of abs(x) be sign(x) not

[sage-devel] Re: c++11, mpirxx, and normaliz problem

On 2014-11-18, Volker Braun wrote: > --=_Part_3954_883918061.1416322498399 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Yes, this is a MPIR bug. In mpir.h, the following takes place: > > #define __need_size_t /* tell gcc stddef.h we only want siz

[sage-devel] Re: c++11, mpirxx, and normaliz problem

On 2014-11-18, Dima Pasechnik wrote: > basically, current (upstream) normaliz does not compile with gcc 4.9.2; > (with Sage 4.5.beta0). > I tracked it down to the following test, showing that mpir(xx) does > something strange... As Jeroen mentiones on the mpir list, a workaround is suggested in

[sage-devel] Re: c++11, mpirxx, and normaliz problem

Yes, this is a MPIR bug. In mpir.h, the following takes place: #define __need_size_t /* tell gcc stddef.h we only want size_t */ #include /* for size_t */ As expected from changing implementation macros, his breaks sooner or later: $ gcc -std=c++11 align.cc In file included from align.cc:2

Re: [sage-devel] c++11, mpirxx, and normaliz problem

Looks like this might be the root: https://gcc.gnu.org/gcc-4.9/porting_to.html Unformatted quoting: """ Header changes The header was updated for C++11 support and this breaks some libraries which misuse macros meant for internal use by GCC only. For instance with GMP versions up to 5.1.3, yo

[sage-devel] c++11, mpirxx, and normaliz problem

basically, current (upstream) normaliz does not compile with gcc 4.9.2; (with Sage 4.5.beta0). I tracked it down to the following test, showing that mpir(xx) does something strange... $ cat b.cpp #include int main() { return alignof(std::max_align_t); } $ g++ -std=c++11 -c b.cpp In file i

Re: [sage-devel] Re: About recmpilations caused by Git

On Tue, Nov 18, 2014 at 03:35:57AM -0800, Volker Braun wrote: > The problem with union file systems is that you don't have a good option on > OSX (e.g. forget about the built-in union fs). Hi Volker. i dont think that reviews made on non-OSX computers are inferior. and, nobody would keep you fr

Re: [sage-devel] Bug in abs(I*x).diff(x)

On Tue, Nov 18, 2014 at 5:57 AM, Bill Page wrote: > On 17 November 2014 23:16, Ondřej Čertík wrote: >> Hi Bill, >> >> Thanks for the clarification. So your point is that 2) is not >> sufficient, that we really need two Wirtinger derivatives --- it's >> just that one can be expressed using the oth

[sage-devel] Re: Code of Conduct

> > > >> rjf, I (once again) *highly* recommend Steven Weber's > >> http://www.hup.harvard.edu/catalog.php?isbn=9780674018587 "The Success > of > >> Open Source", in particular the chapters on self-governance in open > source, > >> as a place to start reading about this. > >> > > > > Iro

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 17 November 2014 23:16, Ondřej Čertík wrote: > Hi Bill, > > Thanks for the clarification. So your point is that 2) is not > sufficient, that we really need two Wirtinger derivatives --- it's > just that one can be expressed using the other and a conjugate, > so perhaps CAS can only return one,

[sage-devel] Re: sage-6.4 fallout: the normaliz package is now broken

On 2014-11-15, William Stein wrote: > Hi, > > I guess the upgrade to patch broke more optional packages: > > sage -i normaliz > ... > > gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) > > patching file source/Makefile.configuration > (Stripping trail

[sage-devel] Re: checkout for closed tickets which are not yet in develop

> > What is our policy concerning deleting branches from the trac repositories > (e.g., I usually delete all branches on trac which are merged in a stable > release, say, just to unclutter the name space there)? > > The current workflow (replacing the branch by the commit id when closing > the

Re: [sage-devel] Re: About recmpilations caused by Git

> > > > Also part of the problem is the use of 'make' that is recommended > Yes, and there are good reasons for this. > > > I've gone back to sage -b. > Please don't, or at the very least don't ever report a bug or failing > doctest without doing "make" first. > > The problem with "sage -b" i

Re: [sage-devel] Re: About recmpilations caused by Git

On 2014-11-17 15:03, kcrisman wrote: Also part of the problem is the use of 'make' that is recommended Yes, and there are good reasons for this. I've gone back to sage -b. Please don't, or at the very least don't ever report a bug or failing doctest without doing "make" first. The problem w

Re: [sage-devel] About recmpilations caused by Git

Ticket #17286 has been merged in sage-6.5.beta0 which should solve most of the problems mentioned in this thread. One major cause of recompilation what that Python implicitly depended on $SAGE_ROOT/configure, which changes in every single Sage version. So going from one beta to a different bet

Re: [sage-devel] Octave interface broken

Hi I have 6.3 I am glad to see this is fixed in 6.4. I do not see 6.4 binaries for Ubuntu 14.04, so I have not updated the PPA yet. ftp://ftp.sun.ac.za/pub/mirrors/www.sagemath.org/linux/64bit/index.html Regards, Jan On 18 November 2014 13:15, Francois Bissey wrote: > Which version of sage? I

Re: [sage-devel] Re: About recmpilations caused by Git

On Tuesday, November 18, 2014 8:12:42 AM UTC, Felix Salfelder wrote: > > - aufs [2]. use an overlay for reviewing. afterwards discard it and return > to the previous state. > The problem with union file systems is that you don't have a good option on OSX (e.g. forget about the built-in union

[sage-devel] Re: checkout for closed tickets which are not yet in develop

Am 2014-11-16 um 12:27 schrieb Volker Braun: > On Sunday, November 16, 2014 6:34:56 AM UTC, Clemens Heuberger wrote: > > > Works for me, possibly because I have a newer git. > Can it be that it works for you because the commit > ec0aae9358f5204a3db6406b2c2f2818a78f5892 (this is the act

Re: [sage-devel] Octave interface broken

Which version of sage? It should have been fixed in 6.4. We initially spotted this in sage-on-gentoo and someone finally opened an issue for it that got merged in 6.4: https://github.com/cschwan/sage-on-gentoo/issues/289 François > On 18/11/2014, at 23:48, Jan Groenewald wrote: > > Hi > > Ori

Re: [sage-devel] Re: Relabeling posets vs. lattices

Hello ! > Because after thinking this it kind of feels wrong. A class should not > "know" other classes deriving from it. Yes yes. Well, "the correct way" would be to implement .relabel() in every superclass. But like for "disjoint union" that is a lot of code (+doc) for almost nothing, so listin

Re: [sage-devel] Re: Relabeling posets vs. lattices

On Tue, 18 Nov 2014, Nathann Cohen wrote: Why don't you do what you did for ordinal sum, and change the code of Poset to deal with the "lattice" case ? Because after thinking this it kind of feels wrong. A class should not "know" other classes deriving from it. And in theory someone could als

[sage-devel] Re: Octave interface broken

Hi Original problem: a PPA sage has a sage installation with system-wide files owned by root. Such a user running octave('1+1') get permission denied: /usr/lib/sagemath/local/share/ sage/ext/octave/user instead of running octave code (it does not clearly say those don't exist, it just says permis

[sage-devel] Re: Relabeling posets vs. lattices

Hello ! Well, I would say that rewriting Poset.relabel to use the master's class directly (which would be Poset,or Lattice, or UpperSemiLattice ...) would be too much, though I do not think that it would ever lead to actual mistake. Why don't you do what you did for disjoint union, and change t

[sage-devel] Relabeling posets vs. lattices

This says that after relabeling a lattice we have a poset: L=LatticePoset({0:[1]}) type(L.relabel(lambda n: n+1)) Should this be corrected at posets.py, or should lattices.py contain wrapper functions? As a code perspective it seems logical to a class derived from poset to define it's own func

[sage-devel] Re: Code of Conduct

On 2014-11-15, rjf wrote: > --=_Part_62_455616071.1416063379935 > Content-Type: text/plain; charset=UTF-8 > > > > On Friday, November 14, 2014 7:06:56 AM UTC-8, kcrisman wrote: >> >> >>> If person A verbally attacks person B, I still think it does not help to >>> show a *disapproving* reactio

[sage-devel] Re: Code of Conduct

On 2014-11-14, Simon King wrote: > Hi Travis, > > On 2014-11-14, Travis Scrimshaw wrote: >>To give a counterpoint to Simon's analogy, we agree that bullying is >> bad, but by the rules, we can tell bullies explicitly what their doing is >> wrong, why we can't push the bullies down, and expl

[sage-devel] Octave interface broken

Hi By default our PPA installation does not have the folders octave and user in /usr/lib/sagemath/local/share/sage/ext/octave/user And /usr/lib/sagemath/local/share/sage/ext/ is owned by root in a system-wide install. I can add these two folders to the PPA, but would rather have then added upstr

Re: [sage-devel] Re: About recmpilations caused by Git

On Mon, Nov 17, 2014 at 05:57:53PM -0800, Andrew wrote: > When the branch is finally ready for review it has to be merged with the > latest development branch, so you can't avoid this indefinitely. As with > Nathan, I'm reluctant to continuously switch between versions because of > the compile t