[sage-devel] TRe: approve github actions

Thank you, yes, I now have the appropriate button! Wonderful! On Tuesday 14 May 2024 at 23:55:01 UTC+2 julian...@fsfe.org wrote: > I granted "write" permissions to you. That seems to be the required > permission to approve workflow runs. > > Can you check that it works now? > > julian > > PS:

[sage-devel] approve github actions

Could I have the right to approve github actions? Otherwise, mentoring the GSOC student over github is a pain. Best wishes, Martin (mantepse) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: scalar multiplication of module element fails

I think I've got it. In `free_module_element.pyx` the method `FreeModuleElement_generic_dense._lmul_` does the following: cpdef _lmul_(self, Element right): """ EXAMPLES:: sage: v = vector([-1,0,3,pi]) # needs

[sage-devel] Re: scalar multiplication of module element fails

Update: I'm afraid I misunderstood - this does call __mul__, right? On Friday 10 May 2024 at 15:20:07 UTC+2 Martin R wrote: > I am trying to fix > https://github.com/sagemath/sage/pull/37976#issuecomment-2104464722 > > Briefly: > > sage: h = SymmetricFunctions(QQ).h() > sage: v =

[sage-devel] scalar multiplication of module element fails

I am trying to fix https://github.com/sagemath/sage/pull/37976#issuecomment-2104464722 Briefly: sage: h = SymmetricFunctions(QQ).h() sage: v = vector([h[3]+h[2,1]]) sage: v * (-111) ({[3]: 1, [2, 1]: 1}) One reason for this is possibly sage: a = coercion_model.get_action(v.parent(), ZZ,

[sage-devel] collect names of all optional arguments used in sage

Dear all! I thought it may make sense to have an easy way to find the names of all optional (i.e., keyword) arguments used in sage, ideally as a dictionary mapping names to the methods where they are used. So, for example, one entry might be (schematically) (' rank', [random_subspaces_matrix,

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

Another example is large-scale pure math computation on clusters. Because of Sage's size and the nature of distributive file systems, the time to startup Sage can be 30 seconds or more, which complicates things if you want to do 100,000 calculations that are only 10 seconds each. I agree

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Thursday 25 April 2024 at 05:13:37 UTC+2 Matthias Koeppe wrote: On Wednesday, April 24, 2024 at 1:07:44 AM UTC-7 Martin R wrote: You mentioned several times, that discoverability is an important aspect. Do you have any evidence to support that? I mentioned "discoverability" in the

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

Dear Matthias! You mentioned several times, that discoverability is an important aspect. Do you have any evidence to support that? Wouldn't people in the python world who need a serious amount of math know of sage anyway, and then, if they cannot rely on all of sage because that is too

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

If I understand correctly, the current proposal does not mind if some things don't work or could be replaced without too much effort. For example, Dima might have referred to the fact that OrderedPartitions.cardinality uses gap, even though it is in sagemath-combinat. The gap dependency in

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

Thank you for this list. I still don't see why you would name these distributions as you do, and why you collect them as you do. For example, as far as I know, symmetrica is currently essentially only used by symmetric functions, Schubert polynomials. So, if symmetrica is such a burden to

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

Dear Matthias, This doesn't make sense to me. Why would you separate mathematics into packages that have no more external dependencies from others, which at the same time may grow internal dependencies over time? I can imagine that it would make sense to make as much as possible into runtime

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

A follow-up question: do I understand correctly that common lisp (via maxima) is the main dependency that prevents sagemath from being pip-installable? All the best, Martin On Friday 19 April 2024 at 21:34:06 UTC+2 Martin R wrote: > On Friday 19 April 2024 at 20:08:51 UTC+2 Matthias Koeppe

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

On Friday 19 April 2024 at 20:08:51 UTC+2 Matthias Koeppe wrote: On Friday, April 19, 2024 at 5:08:02 AM UTC-7 Martin R wrote: 2.) If this is about dependencies on other software, why aren't the distributions named after these dependencies? Martin, I have answered this already when you

[sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

Dear Matthias! *> What is the modularization project?* The Sage developer community has long been aware of the severe problems that the monolithic design of Sage has brought. See in particular the lively 2016 sage-devel thread "How we develop Sage"

[sage-devel] Re: VOTE: Revert merged PR with unreviewed dependencies

+1, yes, the unintended merge should be reverted. Martin On Thursday 18 April 2024 at 17:54:26 UTC+2 David Roe wrote: > Hi all, > Sage has had a review process for over 15 years, but a combination of > recent changes has led to the merging of a PR into sage-10.4.beta3 of a > change (#36964

[sage-devel] Re: Question about change_ring

Ah, yes! There are constructions of parents where the second argument is not the base ring, and there are also constructions with higher arity. So, I guess that, to be on the safe side, a generic change_ring method would have to check `self.construction()[1] == self.base_ring()`. Martin On

[sage-devel] Question about change_ring

Dear all, For parents in the category `Set`, sage has a method `construction`, which yields either None, or a functor F and a parent R, such that F(R) yields the original parent, see below for the docstring. Many parents implement a method `change_ring`, which returns the parent with the base

Re: [sage-devel] Urgent: Please vote on these "disputed" PRs

Please don't! Martin On Wednesday 10 April 2024 at 00:39:39 UTC+2 Dima Pasechnik wrote: > I think I will quit the Sage project as soon as decisions on technical > merits of PRs and issues will start to be taken in a nakedly political way. > > I am very strongly against any political overtones

[sage-devel] Problem with InfinitePolynomialRing

The following is giving me a headache. In a fresh session, do sage: R. = InfinitePolynomialRing(SR) sage: p = a[0].polynomial() sage: R(p) ... RuntimeError: Symbolic Ring still using old coercion framework I tried all day to make sense of the element_constructor of the InfinitePolynomialRIng

[sage-devel] Re: Vote: changes to Sage's Code of Conduct

+1 I just re-read the whole thing, and I'm quite impressed! Thank you! On Thursday 21 March 2024 at 19:03:34 UTC+1 Matthias Koeppe wrote: > +1. > > On Thursday, March 21, 2024 at 9:51:40 AM UTC-7 John H Palmieri wrote: > >> Dear Sage community, >> >> As announced at >>

Re: [sage-devel] weirdest bug ever

Oh no! Thank you! On Saturday 9 March 2024 at 23:24:20 UTC+1 Gareth Ma wrote: > You typed `mononomials` instead of `monomials`. That's a nono. > > > On 09/03/2024 22:22, 'Martin R' via sage-devel wrote: > > If I store this in a file "bug.sage" I can do: > >

[sage-devel] weirdest bug ever

Consider the following innocent definition: def bug(): """ sage: c = bug() sage: c.coefficients_mononomials() """ R. = QQ[] p = 20*x1^2 + 20*x1*x2 + 20*x2^2 + 20*x1*x3 + 20*x2*x3 + 20*x3^2 return Sequence([p]) If I store this in a file "bug.sage" I can do: sage:

Re: [sage-devel] Re: Labels and Reviewing

I don't know exactly what case of blocking you have in mind, but I'm going to be bold and state that blocking among fellow developers (this is not about private messages, right?) cannot really be a solution, in my opinion: * either there has been a substantial breach of conduct, in which case I

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

Thank you - apparently, I do not have permission to see that group. I'll try to send my vote by email. On Thursday 7 March 2024 at 19:39:14 UTC+1 John H Palmieri wrote: > Martin: it's "sage-conduct" at googlegroups.com. > > On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote: > >>

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

For some reason, I cannot see the name of the newsgroup I should be sending my vote to. (I am using the google groups webinterface) Martin On Thursday 7 March 2024 at 19:13:42 UTC+1 David Roe wrote: > Dear Sage developers, > Thank you for those you nominated people for the committee following

Re: [sage-devel] sensational bug!

t fail again? > > Dima > > On Wed, Mar 6, 2024 at 9:47 AM 'Martin R' via sage-devel < > sage-...@googlegroups.com> wrote: > >> On >> https://github.com/sagemath/sage/actions/runs/8168335359/job/22330264302?pr=37545 >> >> I see >> >> sage

[sage-devel] sensational bug!

On https://github.com/sagemath/sage/actions/runs/8168335359/job/22330264302?pr=37545 I see sage -t --long --random-seed=286735480429121101562228604801325644303 src/sage/rings/tests.py ** Error: Failed example:: Got: Random

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

I don't get it - are my previous messages invisible? 1st Message: I don't understand - `degree` doesn't make much sense for Laurent series - there is no way to determine the degree of a LaurentSeries and no way to determine the degree of a LazyLaurentSeries with one minor exception - which is

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

On Friday 1 March 2024 at 19:03:35 UTC+1 Dima Pasechnik wrote: On Fri, Mar 1, 2024 at 5:58 PM 'Martin R' via sage-devel < sage-...@googlegroups.com> wrote: I don't understand - `degree` doesn't make much sense for Laurent series - there is no way to determine the degree of a Laurent

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

I don't understand - `degree` doesn't make much sense for Laurent series - there is no way to determine the degree of a LaurentSeries and no way to determine the degree of a LazyLaurentSeries with one minor exception - which is when it is known that the series terminates, but that's rare. On

Re: [sage-devel] Re: Sage's Code of Conduct: proposed changes

t; all of these suggestions are appropriate to discuss, and that sage-devel is > probably a better venue for discussion like this than the PR. > > On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel < > sage-...@googlegroups.com> wrote: > >> I would like to ask whether we might

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

Could you expand on 'the whole valuation interpretation of "degree" goes out of the window'? What do you mean with "valuation interpretation"? Is raising an exception out of the question? On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote: > On Friday 1 March 2024 at 04:26:43 UTC-8

[sage-devel] Permissions on github

I couldn't find the appropriate place to ask (and I think that this should be fixed): how can I give someone the permission to modify labels, I think that's called triage team now? User name would be nadialafreniere. Thank you, Martin -- You received this message because you are subscribed

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

On Friday 1 March 2024 at 12:15:36 UTC+1 John Cremona wrote: On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik wrote: On Fri, Mar 1, 2024 at 10:24 AM John Cremona wrote: On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik wrote: On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel < s

[sage-devel] Re: Sage's Code of Conduct: proposed changes

I would like to ask whether we might want to add some of the following to the code of conduct, I could not find it covered there. I admit that it is unclear to me whether the discussion should be on pull requests only. I don't want to add the following to John's pull request, because it

Re: [sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

I'd be OK with raising an exception or with -oo, but it should be uniform, and I think it should be the same for polynomials, Laurent polynomials and in the same spirit for degree and valuation. It might be best to raise an exception, because this ensures that the zero polynomial gets special

[sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

Yes, I'd say so. On Wednesday 28 February 2024 at 14:57:26 UTC+1 Giacomo Pope wrote: > Ahh ok, thank you. Considering the following output I think a PR to make > the degree of zero for these Laurent classes -Infinity is reasonable? > > ``` > sage: R. = LaurentSeriesRing(QQ) > sage:

[sage-devel] Re: linear equations over finite fields

Quick fix needs review. Possibly checking for performance regressions would be good. On Wednesday 28 February 2024 at 14:35:36 UTC+1 Martin R wrote: > As it turns out after some digging, this is > https://github.com/sagemath/sage/issues/28586 and set to "critical" since > at least October

[sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

Sorry, I confused it with valuation, but I guess it is still a related question. On Wednesday 28 February 2024 at 14:36:35 UTC+1 Giacomo Pope wrote: > This is not what I see on the current beta: > > sage: R. = LaurentSeriesRing(QQ) > sage: R.zero().degree() > -1 > sage: R. =

[sage-devel] Re: linear equations over finite fields

As it turns out after some digging, this is https://github.com/sagemath/sage/issues/28586 and set to "critical" since at least October 2019. On Wednesday 28 February 2024 at 13:03:44 UTC+1 Martin R wrote: > Dear all, > > I just discovered the following - was this a problem in earlier sage >

[sage-devel] Re: Degree of the zero polynomial ring for `LaurentPolynomialRing`

LazyLaurentSeriesRing(QQ) currently gives +Infinity. On Wednesday 28 February 2024 at 12:50:45 UTC+1 Giacomo Pope wrote: > While chasing various bugs which appeared in the CI, I ended up adding a > small method for computing random elements for the LaurentPolynomialRing > class. > > When

[sage-devel] linear equations over finite fields

Dear all, I just discovered the following - was this a problem in earlier sage versions, too? See https://github.com/sagemath/sage/issues/37496 Best wishes, Martin sage: m = matrix(GF(3), [[2]]) sage: b = vector(GF(3), [1]) sage: m.solve_right(b) (2) sage: m = matrix(GF(3), [[2]],

[sage-devel] Re: containment

Oh dear, I should have taken a break. Thank you. On Saturday 24 February 2024 at 22:47:49 UTC+1 dmo...@deductivepress.ca wrote: > Yes. Elements of F are linear combinations of the basis vectors a and b. > Since 5/3 is not such a linear combination, it is certainly not in F. > > On Saturday,

[sage-devel] containment

In combinat/free_module.py, CombinatorialFreeModule, I find the doctest below. Do we *really* want that 5/3 is not in CombinatorialFreeModule(QQ,["a", "b"])??? Martin def __contains__(self, x): """ TESTS:: sage: F = CombinatorialFreeModule(QQ,["a", "b"])

[sage-devel] Re: Help with coercion / action for tensor product

sage: h = SymmetricFunctions(QQ).h() sage: S = LazySymmetricFunctions(h) sage: E = S(lambda n: h[n]) sage: T = LazySymmetricFunctions(tensor([h, h])) sage: X = tensor([h[1],h[[]]]) sage: Y = tensor([h[[]],h[1]]) sage: A = T.undefined() sage: B = T.undefined() sage: T.define_implicitly([A, B], [A -

[sage-devel] Re: Help with coercion / action for tensor product

I just prepared a very long answer. Doing so I had to check something in my code. This in turn lead me to discover a bug, which might slightly change things. I am too tired right now to fix the bug (it might not be easy), so please give me a night. This might reduce the problem to nothing,

[sage-devel] Help with coercion / action for tensor product

Dear all! I badly need help to make the following work. Let M be a module over a ring Q, and let R be a ring with a coercion from Q to R. Then I want to be able to multiply elements in R with elements in tensor products of M. This is https://github.com/sagemath/sage/pull/37413, and is

Re: [sage-devel] Re: (Urgent) cannot install pyscipopt

that! Thank you so much! > > Martin > > On Friday 16 February 2024 at 20:31:15 UTC+1 Dima Pasechnik wrote: > > On Fri, Feb 16, 2024 at 7:25 PM 'Martin R' via sage-devel < > sage-...@googlegroups.com> wrote: > > Oh no, sorry, this was a typo! > > YES SCIP WORK

Re: [sage-devel] Re: (Urgent) cannot install pyscipopt

of these a long time ago, but apparently, they never made it into sage. what a waste). I'll look into the other options after that! Thank you so much! Martin On Friday 16 February 2024 at 20:31:15 UTC+1 Dima Pasechnik wrote: On Fri, Feb 16, 2024 at 7:25 PM 'Martin R' via sage-devel < s

Re: [sage-devel] Re: (Urgent) cannot install pyscipopt

+1 Dima Pasechnik wrote: > You need an SPD solver - it's a different package, scip_sdp, not pyscipopt. > Try > > make scip_sdp > > (probably followed up by "make build", just in case) > > On 16 February 2024 18:39:52 GMT, 'Martin R' via sage-devel < > sage-..

[sage-devel] Re: (Urgent) cannot install pyscipopt

Any hope left? If not, which version of sage do I have to downgrade to? Thank you for all the hints so far! Martin martin@toolbox:~/sage-trac$ ./sage -pip install pyscipopt Collecting pyscipopt Downloading PySCIPOpt-4.4.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata

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

The "math" activity might be useful, but the "documentation" label is currently also used for issues that have nothing to do with math. So either relabel those or exclude "documentation". On Tuesday 13 February 2024 at 08:34:32 UTC+1 Kwankyu Lee wrote: On Monday, February 12, 2024 at 3:42:55 

[sage-devel] Re: feedback on construction functor for symmetric functions

Thank you! To get a working prototype for the functional equations solver, the coercion issue with tensors is the most interesting issue. I am already quite happy that it works with symmetric functions in one variable! Apart from technicalities, it might then be interesting to explore whether

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

For me - personally - the problem that Vincent pointed out has an emotional flavour: most of the threads on sage-devel are on (lcertainly important) technicalities. The discussion about how to implement math has mostly moved to github, and split into very very many issues that are hard to find

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

Found the page: https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md On Monday 12 February 2024 at 14:18:12 UTC+1 Martin R wrote: > I suggest to remove "no dark arts required", because, at least to me, many > of the issues I struggle with actually do require

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

I suggest to remove "no dark arts required", because, at least to me, many of the issues I struggle with actually do require very little knowledge of mathematics but a considerable amount of knowledge of the way sage works. Apart from that, I was looking for the tutorial telling me how to

[sage-devel] Re: feedback on construction functor for symmetric functions

Apart from that, I think the last bit I need to do is to make the TensorProductFunctor inherit from MultivariateConstructionFunctor, to make coercion work for things like sage: h = SymmetricFunctions(ZZ).h() sage: T = tensor([h, h]) sage: T.base_ring() Integer Ring sage: 1/2*T.an_element()

[sage-devel] feedback on construction functor for symmetric functions

At https://github.com/sagemath/sage/pull/37220, I implemented a (simple minded) construction functor for symmetric functions. The only major user visible change should be that sage: sZ = SymmetricFunctions(ZZ).s() sage: sQ = SymmetricFunctions(QQ).s() sage: sZ[1,1] + sQ[2] s[1,1] + s[2] now

[sage-devel] morphisms between multivariate polynomial rings

I was a bit surprised about the following: sage: k = ZZ["q"].hom(QQ["q"]) sage: isinstance(k, Morphism) True sage: m = ZZ["q,t"].hom(QQ["q,t"]) sage: isinstance(m, Morphism) False However, I vaguely recall a discussion about morphisms between multivariate polynomial rings being problematic.

[sage-devel] Help with implementing coercion for symmetric functions needed

I think I made good progress, but would appreciate help with https://github.com/sagemath/sage/pull/37220 now. Adding '_has_coercion_from_' breaks base change (which uses __call__) between certain bases of symmetric functions. Martin -- You received this message because you are subscribed to

[sage-devel] Re: Help needed with UniqueRepresentation (of SymmetricFunctions)

Thank you for the explanation. I would be very surprised about `R.=S.jack()`, because the *coefficients* are (usually regarded as) rational functions in `t`, and the *monomials* are Jack symmetric functions. I found the following alternative solution at

[sage-devel] Help needed with UniqueRepresentation (of SymmetricFunctions)

At https://github.com/sagemath/sage/pull/37220 I am trying to provide a construction functor for symmetric functions. I am hitting the following bug, which I hope is easy to fix if one knows the right magic: sage: P. = QQ[] sage: S = SymmetricFunctions(P) sage: S.jack().P() == S.jack(t=t).P()

[sage-devel] Unify error for trying to invert non-invertible elements

Dear all, currently, when trying to invert a non-invertible element, one of the following errors is raised (found using `grep -r --include=*.{py,pyx} --color -nH --null -e "Error(.*invertible" *`): - 21 ValueError('{} is not invertible') - 11 ZeroDivisionError("element is not

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

I would like to propose the exact same project I had for last year again, but I am currently at a conference and additionally don't see how I could edit the page. Martin On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote: > Sorry for the multiple messages. > > For potential

[sage-devel] Re: interface to Fricas question. Special function weierstrassPInverse

Yes, the current strategy is that any expression in FriCAS that sage does not know is turned into a symbolic function with the same name: try: fun = symbol_table["fricas"][(fun_string, len(args))] except KeyError: try: # to handle the case

[sage-devel] Ring of undetermined coefficients

Over at https://github.com/sagemath/sage/pull/37033 I am hitting the following question: Is it possible to have a ring UndeterminedCoefficientRing(R) which, for every functorial construction F(R) has pushout F(UndeterminedCoefficientRing(R)). I am not sure whether the phrasing of the question

[sage-devel] Re: Desparate for help

I have done more digging. If I am not mistaken, what governs the coercion is the function `pushout` in `categories/pushout.py`. For each construction functor there is a hardcoded rank, such as 9.5 for the InfinitePolynomialFunctor, 10 for the MatrixFunctor, or 9 for the PolynomialFunctor and

[sage-devel] Re: Desparate for help

OK, possibly I now understand Matthias Köppe's comment on the PR. He said that the pushout of R and S looks suspicious (this is indeed computed in ModuleAction.__init__ and seems to govern the process): sage: R Univariate Polynomial Ring in z over Rational Field sage: S Univariate Polynomial

[sage-devel] Re: Desparate for help

I find the MatrixSpace example interesting: sage: R = MatrixSpace(QQ, 1) sage: P = PolynomialRing(R, names="z") sage: Q = PolynomialRing(QQ, names="z") sage: Q.gen() * P.gen() [z]*z sage: P.gen() * Q.gen() [z]*z sage: coercion_model.analyse(P.gen(), Q.gen(), operator.mul) (['Action discovered.',

[sage-devel] Re: Desparate for help

How can I find out what causes this? How can I find out where this action is defined? I played around a little, but without any insights. It seems that most of the time, the coercion tries to do the embedding in the base ring, but not always. The MatrixSpace seems to be another exception.

[sage-devel] Re: Desparate for help

I am not quite sure I understand how this works / what is used: sage: pushout(e.parent(), z.parent()) Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q over Rational Field sage: coercion_model.common_parent(z, e) Multivariate

[sage-devel] Re: Desparate for help

Hm, that's somewhat unfortunate - I don't see how to work around it. I guess I would have to force all elements to be in P (using the notation of the example), but this is, I think, not possible. Do you know where this behaviour is determined? On Friday 12 January 2024 at 22:09:41 UTC+1 Nils

[sage-devel] Re: Desparate for help

I made a tiny bit of progress, and now face the following problem: sage: I. = InfinitePolynomialRing(QQ) sage: P. = I[] sage: e = z*q sage: Q. = QQ[] sage: z*e z*z*q Is this correct behaviour? For comparison: sage: I. = QQ[] sage: P. = I[] sage: e = z*q sage: Q. = QQ[] sage: z*e z^2*q

[sage-devel] Desparate for help

I am fighting with various bugs involving substitution / composing into polynomials, mostly involving the InfinitePolynomialRIng, for example https://github.com/sagemath/sage/issues/37047 I would appreciate help *a lot*. The background is, that I have mostly implemented a solver for lazy

[sage-devel] libsingular polynomial rings that look the same but are different

Does anybody have any idea how the following could happen? (c is an element of R = InfinitePolynomialRing(QQ, "FESDUMMY"), and I set P = R.polynomial_ring()) Martin ipdb> p c.polynomial().parent() Multivariate Polynomial Ring in FESDUMMY_1, FESDUMMY_0 over Rational Field ipdb> p R Multivariate

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

I just followed a few of the links Matthias posted today, and I must admit that I do not understand a word. Karl pointed out that: > I don't think it's off-topic to once again point out that this way of phrasing it is very developer-centric. That's not a wrong way to look at it, but an

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

Maybe it would make sense to appoint a group of editors, rather than a single editor, and this group decides per vote? I'd feel much better if the responsibility is at least a little bit distributed between several people, and, most importantly, people who have been around for some time.

[sage-devel] Re: Regarding deprecation of a property

I like this idea much better! What would be a good name? Brainstorming: `coefficient_system`, `coefficients`, `coefficients_monomials`, `coefficient_matrix_monomial_vector`... On Wednesday 10 January 2024 at 09:06:36 UTC+1 Nils Bruin wrote: > deprecation in a way that allows code to be

[sage-devel] approve workflow?

I am currently engaging with new contributors, and it seems that for these, the github checks (linter, build, etc.) are not run automatically, see https://github.com/sagemath/sage/pull/36811 for an example. Should I be able to "approve the workflow"? Best wishes, Martin -- You received this

[sage-devel] Re: Workaround for converting variables into the InfinitePolynomialRing

from sage.rings.polynomial.infinite_polynomial_element import InfinitePolynomial_dense is my friend! On Wednesday, 22 November 2023 at 11:40:12 UTC+1 Martin R wrote: > I need the variables of a polynomial c in InfinitePolynomialRing(SR) as an > element of that ring (rather than as an element

[sage-devel] Workaround for converting variables into the InfinitePolynomialRing

I need the variables of a polynomial c in InfinitePolynomialRing(SR) as an element of that ring (rather than as an element of the PolynomialRing). I understand that polynomials are hard, but does anybody see a workaround? Martin sage: R. = InfinitePolynomialRing(SR) sage: c = 3*a[0] sage:

[sage-devel] Re: keywords in github

That's an excellent suggestion, it might work quite well for me. I just created a list of issues and pull requests for the lazy series theme. One thing which would be nice, but is probably not possible: I'd like to see in the sagemath/sage list of issues whether an issue happens to be part of

[sage-devel] Re: keywords in github

It was possible to click on a keyword in the ticket description and get all the tickets with the same keyword. On Thursday, 28 September 2023 at 21:46:57 UTC+2 Matthias Koeppe wrote: > On Trac, keywords were completely free-form; there was nothing to click, > and there wasn't an agreement

[sage-devel] keywords in github

I would like to have trac keywords back. Searching issues in github seems quite difficult, for example, it seems that wildcards are not supported: "is:pr is:open lazypower" finds nothing wereas "is:pr is:open lazypowerseries" does. On trac, I used keywords to collect the issues that

[sage-devel] Re: Contributing to SageMath

Maybe you also find this helpful: https://github.com/sagemath/sage/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+ On Monday, 25 September 2023 at 07:59:06 UTC+2 Saatvik Rao wrote: > Hello developers, > > I am currently doing a project course that involves making active >

Re: [sage-devel] remove definitions of __ne__?

Thank you! On Saturday, 2 September 2023 at 13:44:46 UTC+2 Oscar Benjamin wrote: > On Sat, 2 Sept 2023 at 12:15, 'Martin R' via sage-devel > wrote: > > > > On Saturday, 2 September 2023 at 11:39:12 UTC+2 Oscar Benjamin wrote: > > > > On Sat, 2 Sept 2023 at 08

Re: [sage-devel] remove definitions of __ne__?

eptember 2023 at 11:39:12 UTC+2 Oscar Benjamin wrote: > > On Sat, 2 Sept 2023 at 08:44, 'Martin R' via sage-devel > wrote: > > ... > > It is easy for this sort of thing to be overlooked in test code and in > fact > messing with __eq__/__ne__ (more so __eq__) can i

Re: [sage-devel] remove definitions of __ne__?

On Saturday, 2 September 2023 at 11:39:12 UTC+2 Oscar Benjamin wrote: On Sat, 2 Sept 2023 at 08:44, 'Martin R' via sage-devel wrote: ... It is easy for this sort of thing to be overlooked in test code and in fact messing with __eq__/__ne__ (more so __eq__) can invalidate much

[sage-devel] remove definitions of __ne__?

If I understand correctly, in python3 it is no longer necessary to implement __ne__, if it is simply the negation of __eq__. There are currently about 200 definitions of the form def __ne__(self, other): return not (self == other) I think it would be good to remove them. Travis

[sage-devel] Re: Contributing to SageMath

One place to start might be https://github.com/sagemath/sage/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+ and look for issues without linked pull request. (I admit, there is not all that much there, currently.) Do you see something there that catches your interest? In my

[sage-devel] pull requests recently updated

I like to see which things are actually being worked on, so I go to pull requests, sort by recently updated. However, this does not quite work, because the updates include things like XXX removed this from the sage-10.1 milestone 2 weeks ago Is

Re: [sage-devel] Re: Ask about the SageMath codebase using ChatGPT

It is very much hallucinating. Worse, it seems that it does not know the sage codebase very well, since sage has actually some dedicated tools helping with the question - in the case at hand, oeis, findstat and Bijectionist come to mind. Is there a fundamental reason it does not know them?

[sage-devel] bug in invariants_of_degree

I need help with https://github.com/sagemath/sage/issues/35684 Is Ben Hutz still around? Martin -- 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

Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.

I fully agree. https://github.com/sagemath/sage/issues/34420 https://github.com/sagemath/sage/issues/32133 https://github.com/sagemath/sage/issues/32143 On Thursday, 27 April 2023 at 11:12:31 UTC+2 Oscar Benjamin wrote: > On Thu, 27 Apr 2023 at 06:25, 'Martin R' via sage-devel >

Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.

If I recall correctly, this is what I did for the FriCAS interface. It would be nice to factor out any common functionality, if possible. On Wednesday, 26 April 2023 at 21:06:30 UTC+2 Oscar Benjamin wrote: > One thing Sage could do with SymPy's RootSum is to call doit which > will expand using

Re: [sage-devel] SCIP problems

ave been stable for a long time > > and were used in several popular extensions. > > In Python 3.11, the frame struct was reorganized to allow performance > > optimizations. Some fields were removed entirely, as they were details > > of the old implementation. > > >

Re: [sage-devel] SCIP problems

13:51:54 UTC+1 Dima Pasechnik wrote: > I believe scip dependencies should include pyscipopt - they don't atm. > > I've run > > ./configure --enable-scip=yes > make build > > and then > sage: default_mip_solver("SCIP") > > still gave an error. After >

[sage-devel] SCIP problems

Dear all, especially Matthias, I have recurring problems to install SCIP. sage -i scip seems to work (the log does not contain any errors), but sage: default_mip_solver("SCIP") fails (ValueError: SCIP is not available. Please refer to the documentation to install it.). This is on

[sage-devel] Re: "files changed" in a pull request

Oh, I see, I was mistaken. For some reason, the pull request I'm supposed to review is partially already in develop. Something went completely wrong here. I see https://github.com/sagemath/sage/pull/34970 which has 19 commits, but also 3b94a2ef915 gh-pr-34970: add is_supergreedy() to

  1   2   3   4   5   6   >