Re: [sage-devel] Re: One year of Sage development on GitHub

> *By the way, an author of a PR needs also the ability to remove "needs work". Hence the author needs to be in the Triage team anyway in our workflow. * Not necessarily! If the *synchronizing trigger* is enabled then the bot would change needs work to needs review on a non draft PR each time a

Re: [sage-devel] Re: missing docker images of sagemath

https://gitlab.com/sagemath/dev/trac/-/pipelines On Mon, Dec 28, 2020 at 11:02 PM Sebastian Oehms wrote: > > Thanks to you both for the hints! Yes, instead of develop I used the > version tag directly. Running docker as you suggested solves the > problem. But, the version tag work

Re: [sage-devel] Re: missing docker images of sagemath

Thanks to you both for the hints! Yes, instead of develop I used the version tag directly. Running docker as you suggested solves the problem. But, the version tag works on a newer CPU (the one causing the crash was an i5 of the 2. generation), as well, and for 9.1.beta1 even on the older CPU.

[sage-devel] Interface to the KnotInfo and LinkInfo databases

Dear All, a couple of months ago I started to implement an interface to the databases of knots and links provided at the web-pages KnotInfo and LinkInfo . The corresponding ticket #30352

[sage-devel] Re: unable to open some sobj-files computed on earlier versions of sage with sage9.1

> > have to figure out a way to save the information in a version-independent > way asap and meanwhile keep using sage8.9. It doesn't sound easy to do. > Let me try to help: As I understood your test case consists of matrices over the integers, right? If you convert it into a pure Python

[sage-devel] Re: The PolynomialRing that isn't

Recently I made some suggestions about that in this thread . Best, Sebastian On Monday, July 27, 2020 at 2:25:16 PM UTC+2, Ricardo Buring wrote: > > Dear sage-devel, > > I would like to drag up this old issue because it is a source

[sage-devel] Re: unable to open some sobj-files computed on earlier versions of sage with sage9.1

Related tickets to this issue are #28302 and #28444! Best, Sebastian On Saturday, July 25, 2020 at 12:03:07 AM UTC+2, Udo Baumgartner wrote: > > I have lots of precomputed data computed by sage8.9 and before

Re: [sage-devel] remove log_html() and other log_*()

On Friday, May 8, 2020 at 11:37:03 AM UTC+2, Markus Wageringel wrote: > > Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms: >> >> But if we talk about users who are not interested in code and strings, >> wouldn't it be more useful for them to have

Re: [sage-devel] remove log_html() and other log_*()

On Thursday, May 7, 2020 at 2:45:51 PM UTC+2, kcrisman wrote: > ... and again many users may not even know there is a directory structure > at all. This is not a "highly peculiar set of disabilities" - rather, the > skill set of people on sage-devel is a "highly peculiar set of abilities",

[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

he computations are done there. At > least this is not super pressing since the Bober implementation is not the > default implementation, but it is definitely something that should be fixed. > > Best, > Travis > > > On Sunday, April 26, 2020 at 6:03:30 AM UTC+10, Sebastian Oe

[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

see also #28549 <https://trac.sagemath.org/ticket/28549>. On Monday, April 20, 2020 at 9:23:52 AM UTC+2, Sebastian Oehms wrote: > > The existenz of the problem already appeared in Friedrich Wiemer's status > report > <https://groups.google.com/forum/#!searchin/sage-deve

[sage-devel] Re: Segmentation fault factoring a multivariate polynomial over IntegerModRing

> > It looks like this problem is going to be fixed by the upgrade to Singular > 4.1.3 (#25993). > Indeed! Thanks for pointing this out! > There is another segmentation fault related to the non-commutative > subsystem Plural, though, causing a doctest failure on the upgrade branch. > See

[sage-devel] Segmentation fault factoring a multivariate polynomial over IntegerModRing

There have been several tickets on segmentation faults concerning the singular interface. Since they are all closed, I think this must be an unknown case: sage: R. = Integers(7)[] sage: p = x**2-1 sage: p.factor() Trying the same with GF works fine: sage: R. = GF(7)[] sage: p = x**2-1 sage:

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

The history of discussions about this issue reaches back over many years, see #10708 and this sage-devel thread and it seems that they all broke down even

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

Enrique, you are right, that doesn't come from the interface, but directely from Singular. Above, I took the wrong ordering. Here the correction: sage: R.=PolynomialRing(QQ,order='neglex') sage: R._singular_init_() polynomial ring, over a field, local ordering // coefficients: QQ // number of

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

I consider this as a bug, too. My guess is, that it comes from the Singular interface: sage: R. = PolynomialRing(QQ, order='negdeglex') sage: f = 1 + x sage: I = R.ideal(x^2) sage: import sage.libs.singular.function_factory sage: reduce = sage.libs.singular.function_factory.ff.reduce sage:

[sage-devel] Re: Method is_unit of QuotientRingElement and PolynomialQuotientRingElement could return True in more cases

This is ticket #29469 <https://trac.sagemath.org/ticket/29469>, now! On Monday, March 30, 2020 at 8:41:40 AM UTC+2, Sebastian Oehms wrote: > > in the former case it raises a NotImplementedError even if inversion is > possible: > > sage: P. = QQ[] > sage: Q

[sage-devel] Method is_unit of QuotientRingElement and PolynomialQuotientRingElement could return True in more cases

in the former case it raises a NotImplementedError even if inversion is possible: sage: P. = QQ[] sage: Q = P.quo([1-x*y]) sage: Q.inject_variables() Defining xbar, ybar sage: ybar.is_unit() Traceback (most recent call last): ... NotImplementedError: but: sage: ~ybar xbar This is marked as a

[sage-devel] Re: Power series do not distinguish between different precisions!

On Wednesday, January 22, 2020 at 2:07:18 PM UTC+1, Marc Mezzarobba wrote: > > [re-posting a reply from a week ago that apparently did not go through > because gmane was moving] > > Nils Bruin wrote: > > This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns > > true, as one would

Re: [sage-devel] Power series do not distinguish between different precisions!

cases that would lead to an alternative)? On Thursday, January 16, 2020 at 12:09:13 AM UTC+1, Nils Bruin wrote: > > > On Wednesday, January 15, 2020 at 12:45:10 PM UTC-8, Sebastian Oehms wrote: >> >> My expectation is that two power series are considered to be equal if &g

Re: [sage-devel] Power series do not distinguish between different precisions!

gt; is still missing some of the newer ones (floating point precision and the > two lattice precisions), but you can pick out the details from the reference > manual > <http://doc.sagemath.org/html/en/reference/padics/sage/rings/padics/factory.html> > > if you're willing to wade thro

[sage-devel] Power series do not distinguish between different precisions!

Dear all, obviously Sage does not distinguish between precisions of power series: sage: R. = PowerSeriesRing(ZZ) sage: O(t).is_zero() True sage: O(t) == O(t**2) True Similarly for p-adics: sage: O(3).is_zero() True sage: O(3) == O(3^2) True sage: This seems to be explicitly intended:

[sage-devel] Localization of integral domains

Since there isn't any Sage-class for localization of integral domains at a set of its elements so far, I've opened ticket #28862 for its realization. Furthermore, I made an initial attempt based on the following example given in the reference pages on

[sage-devel] Coxeter matrix of certain real reflection groups broken!

Hi, is the following a known bug? sage: RH3 = ReflectionGroup(['H', 3]) sage: RH3.coxeter_matrix() Traceback (most recent call last): ... TypeError: 'NotImplementedType' object is not callable This already occurs on stable 8.5 but still was working on 8.1: sage: RH3.coxeter_matrix() [1 3 2]

[sage-devel] Re: How much do we support the casual user

Hello, This topic is a good example, that wrong names can be worse than wrong code. Only the user knows what he has in mind using the adjective "prime": 1) prime in a "narrower sense": being a prime number 2) prime in a "broader sense": being a prime element of a unital commutative ring

Re: [sage-devel] Re: BUGS in tensor products of algebras

Hi Travis, please don't take my poste as a suggestion. I'm not close enough to the subject that I really could do that. I just wanted to point out where the confusion comes from (hoping you have I good Idea what we can do against it). Best, Sebastian 2018-02-26 12:04 GMT+01:00 Travis Scrimshaw

Re: [sage-devel] Re: BUGS in tensor products of algebras

Hi Travis, I had that confusion about the pbw_basis method, as well. From my (non expert) point of view I would have expected the following: What is now your L.pbw_basis() I expected to be L.universal_enveloping_algebra(). This would match what the representation string is telling you: sage:

Re: [sage-devel] 8.2.beta5: compile error in gfortran-7.2.0 on LinuxMint 17.3 / 18

24694 > Note that if you want to try it you’ll need autotools and related packages > to > be installed. > > François > > > On 12/02/2018, at 07:28, Sebastian Oehms <seb@gmail.com > > wrote: > > > > Hello, > > > > since I am new i

[sage-devel] 8.2.beta5: compile error in gfortran-7.2.0 on LinuxMint 17.3 / 18

Hello, since I am new in this fore, let me introduce myself: My name is Sebastian Oehms and I worked as a mathematician in the 90th. I finished my mathematical career already in 1997 (after PhD), but in my leisure time, I still like to think about mathematics. My favorites belong to algebra