[sage-devel] Re: Block TermOrder equality is broken

Hi Kwankyu, On 2018-03-15, Kwankyu Lee wrote: >> sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),lex(5)") >> sage: S = R.change_ring(order="lex(2),lex(4)") >> sage: S.term_order() >> >> Block term order with blocks: >> (Lexicographic term order of length 1, >>

[sage-devel] Re: Block TermOrder equality is broken

On Thursday, March 15, 2018 at 9:59:44 AM UTC+9, Nils Bruin wrote: > > On Thursday, March 15, 2018 at 12:44:39 AM UTC, Kwankyu Lee wrote: >> >> Hi, >> >> Which part of the output you consider wrong? Would you elaborate on the >> "incorrect behaviour"? >> >> > sage: R = PolynomialRing(QQ, 6,

[sage-devel] Re: Block TermOrder equality is broken

On Thursday, March 15, 2018 at 12:44:39 AM UTC, Kwankyu Lee wrote: > > Hi, > > Which part of the output you consider wrong? Would you elaborate on the > "incorrect behaviour"? > > sage: R = PolynomialRing(QQ, 6, 'x', order="lex(1),lex(5)") sage: S = R.change_ring(order="lex(2),lex(4)") sage:

[sage-devel] Re: Block TermOrder equality is broken

Hi, Which part of the output you consider wrong? Would you elaborate on the "incorrect behaviour"? Kwankyu -- 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] Sage Days 100

Dear Sage developers, With Sage Days 96 announced, we are getting close from Sage Days 100! Time to celebrate :-) Shall we take action and decide which upcoming Sage bears a special meaning to us and should hold this symbolic number? I suggest that anyone who cares nominates some Sage

Re: [sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

> On 15/03/2018, at 11:56, Dima Pasechnik wrote: > > On Wednesday, March 14, 2018 at 8:05:05 PM UTC, François Bissey wrote: > I haven’t done on a build on that hardware (power7) in some time. One of my > limitation > is that I cannot install a more modern linux on those

Re: [sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

On Wednesday, March 14, 2018 at 8:05:05 PM UTC, François Bissey wrote: > > I haven’t done on a build on that hardware (power7) in some time. One of > my limitation > is that I cannot install a more modern linux on those without breaking my > access to the GPFS file system. I have a beefy

[sage-devel] Workshop on interfacing (math) software with low level libraries

Dear SageMath developers, This is a reminder of ODK's workshop on "Interfacing (math) software with low-level libraries", April 30th-May 4th in Cernay near Paris: https://github.com/OpenDreamKit/OpenDreamKit/issues/251 Registrations have started (see the web page). Details:

Re: [sage-devel] Nauty as a default generator for graphs

On Fri, Mar 09, 2018 at 08:19:19AM +0200, Jori Mäntysalo wrote: > It is much faster to say sum(1 for _ in graphs.nauty_geng(7)) than sum(1 for > _ in graphs(7)), and after #19919 we have nauty as a standard package. > > Will I break something if I change graphs(n) without any additional >

[sage-devel] Block TermOrder equality is broken

Hi all! There appears to be a bug involving block orders. The equality for TermOrder does not take lengths into account, so two different block orderings are considered equal. As a result, trying to change the block sizes of a polynomial ring has no effect, as the ring is cached. sage: R =

Re: [sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

I haven’t done on a build on that hardware (power7) in some time. One of my limitation is that I cannot install a more modern linux on those without breaking my access to the GPFS file system. I have a beefy gentoo prefix on there though, so I can technically test sage-on-gentoo on top. > On

[sage-devel] Elementary vector calculus with Sage

Hi, After demands from users (see e.g. https://ask.sagemath.org/question/40792/div-grad-and-curl-once-again/ and https://ask.sagemath.org/question/10104/gradient-divergence-curl-and-vector-products/) and a first attempt (see ticket #3021 ), a proposal

Re: [sage-devel] Re: GitHub authentication is live on trac.sagemath.org

On Wed, Mar 14, 2018 at 8:36 AM Erik Bray wrote: > On Wed, Mar 14, 2018 at 12:33 AM, Dima Pasechnik > wrote: > > Perhaps it's a silly suggestion, but what does prevent trac from using an > > external git server, as opposed > > to the internal one? Does

Re: [sage-devel] Re: GitHub authentication is live on trac.sagemath.org

On Wed, Mar 14, 2018 at 12:33 AM, Dima Pasechnik wrote: > Perhaps it's a silly suggestion, but what does prevent trac from using an > external git server, as opposed > to the internal one? Does it need to do git calls which are not possible to > do remotely? > If this is

[sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

I have (or used to have) access to a power 7 machine and so did Francois Bissey IIRC. Things were in quite good shape there. On Wednesday, March 14, 2018 at 1:52:07 PM UTC+1, Dima Pasechnik wrote: > > On Wednesday, March 14, 2018 at 6:42:33 AM UTC, vdelecroix wrote: >> >> As mentioned on the

[sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

On Wednesday, March 14, 2018 at 6:42:33 AM UTC, vdelecroix wrote: > > As mentioned on the ticket, this big-endian incompatibility does not > prevent the inclusion of primecount as an "experimental package" that I > still aim to achieve (the type of the package "experimental", "optional" > or

[sage-devel] Re: Potential bug multiplying permutations from subgroups

On Wednesday, March 14, 2018 at 11:03:36 AM UTC, Andrew wrote: > > Is this me or is it a bug? > > sage: S3 = SymmetricGroup(3) > sage: A3 = S3.subgroup([(1,2,3)]) > : for x in S3: > : print('{:>7}: left coset = {}'.format(x, [x*h for h in A3])) > : print(' : right

Re: [sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

On Wed, Mar 14, 2018 at 12:52 PM, kcrisman wrote: > I recall discussions about this quite a few years ago, and the consensus was > to be careful what you wish for. Too many typos would then mysteriously > become variables. So (even though I certainly think it is a very

Re: [sage-devel] Make JupyterLab a standard package

On Tuesday, March 13, 2018 at 1:33:19 PM UTC-4, Samuel Lelievre wrote: > > Let me try to make the case for making JupyterLab a standard package. > > (1) > > According to a recent post on the Jupyter blog [0], > > - JupyterLab is ready for daily use. > - JupyterLab will eventually replace the

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

I recall discussions about this quite a few years ago, and the consensus was to be careful what you wish for. Too many typos would then mysteriously become variables. So (even though I certainly think it is a very useful facility in many case) the potential for confusion was pretty great. I

Re: [sage-devel] zero problem

Yes QQbar. On 14/03/2018 11:19, Ralf Stephan wrote: Hi, Is the symbolic ring the only one where equality is polymorphic? Comparison in SR can mean 1. "try to prove with certainty" or 2. "check if numeric zero". Other rings may have different features. But are there other such constructs? --

Re: [sage-devel] Potential bug multiplying permutations from subgroups

This is https://trac.sagemath.org/ticket/24612 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group,

[sage-devel] Potential bug multiplying permutations from subgroups

Is this me or is it a bug? sage: S3 = SymmetricGroup(3) sage: A3 = S3.subgroup([(1,2,3)]) : for x in S3: : print('{:>7}: left coset = {}'.format(x, [x*h for h in A3])) : print(' : right coset = {}'.format([h*x for h in A3])) : (): left coset = [(), (1,2,3),

[sage-devel] zero problem

Hi, Is the symbolic ring the only one where equality is polymorphic? Comparison in SR can mean 1. "try to prove with certainty" or 2. "check if numeric zero". Other rings may have different features. But are there other such constructs? -- You received this message because you are subscribed

Re: [sage-devel] Make JupyterLab a standard package

On 2018-03-13 23:26, Samuel Lelièvre wrote: My view is that since it's pip-installable, it's as though it were already an optional package. I have a very different view of that. "optional" implies a level of official support in SageMath. In particular, it should actually build and work

Re: [sage-devel] Make JupyterLab a standard package

On 2018-03-14 02:08, John H Palmieri wrote: I feel like we need another class of package: "pending" (or perhaps some other name) = those which we propose to make standard soon. I agree with Vincent: the build system doesn't need to know that. -- You received this message because you are

Re: [sage-devel] Make JupyterLab a standard package

On 2018-03-13 23:26, Samuel Lelièvre wrote: What would it mean to make it an optional package? Exactly the same as making it a standard package, except that the type is "optional" instead of "standard". Once you do that, it will be trivial to make it a standard package by just changing the

[sage-devel] Re: [sage-support] Re: Has Big-Endian support been deprecated yet?

Dear Kim, As mentioned on the ticket, this big-endian incompatibility does not prevent the inclusion of primecount as an "experimental package" that I still aim to achieve (the type of the package "experimental", "optional" or "standard" is simply a flag). In practice "experimental" means "not

[sage-devel] Re: Move the automatic_names() feature into the Sage interpreter proper

Hi! On 2018-03-13, Erik Bray wrote: > I see no reason this feature needs to be confined to the legacy > Notebook, as opposed to being in Sage proper. Then that feature would > be usable at the command-line, as well as in the Jupyter Notebook. If I understand correctly,