[sage-devel] Re: Regarding deprecation of a property
Okay. On Saturday, January 13, 2024 at 2:22:51 AM UTC+5:30 Nils Bruin wrote: > On Friday 12 January 2024 at 14:50:54 UTC-5 Ruchit Jagodara wrote: > > Okay, so I will make a new function named coefficient_monomials and will > implement the functionality that Lorenz Panny suggested. > Thank you for your help : ) . > > > I think "coefficients_monomials" is a little clearer. ( > coefficient_monomials could be interpreted as "monomials of the > coefficient", which wouldn't make sense). > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/08c7d882-16d2-4747-8787-114840220b9dn%40googlegroups.com.
[sage-devel] Re: Desparate for help
This might be at fault: sage: coercion_model.analyse(q,e) (['Action discovered.', Left scalar multiplication by Multivariate Polynomial Ring in z, q over Rational Field on Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F over Rational Field], Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q over Rational Field) it looks like somehow an action is found before "common parent" multiplication is used. On Friday 12 January 2024 at 17:24:00 UTC-5 Martin R wrote: 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 Polynomial Ring in z, q over Infinite polynomial ring in F over Rational Field Martin On Friday 12 January 2024 at 22:47:49 UTC+1 Martin R wrote: 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 Bruin wrote: On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote: 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? I don't think it's desperately wrong. To sage, these structures look like: sage: P.construction() (MPoly[z,q], Infinite polynomial ring in F over Rational Field) sage: Q.construction() (MPoly[z,q], Rational Field) sage: parent(z*e).construction() (MPoly[z,q], Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q over Rational Field) Note that an "infinite polynomial ring" is a different object than an MPoly, and obviously it has different rules/priorities for finding common overstructures. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/52d111fa-9539-46c0-8c16-a8f775a88bd3n%40googlegroups.com.
[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 Polynomial Ring in z, q over Infinite polynomial ring in F over Rational Field Martin On Friday 12 January 2024 at 22:47:49 UTC+1 Martin R wrote: > 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 Bruin wrote: > >> On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote: >> >> 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? >> >> I don't think it's desperately wrong. To sage, these structures look like: >> >> sage: P.construction() >> (MPoly[z,q], Infinite polynomial ring in F over Rational Field) >> sage: Q.construction() >> (MPoly[z,q], Rational Field) >> sage: parent(z*e).construction() >> (MPoly[z,q], >> Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q >> over Rational Field) >> >> Note that an "infinite polynomial ring" is a different object than an >> MPoly, and obviously it has different rules/priorities for finding common >> overstructures. >> >> > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9087dfc6-f12d-4502-bf26-686a76eb3196n%40googlegroups.com.
Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
One way or another, no faithful packaging of Sage the distro exists, besides Sage the distro itself. The reason is that it's too big, too verbose with it's 400 packages, most of which are just unpatched PyPI packages, pinned to relatively random versions, providing Python, Jupyter and Sphinx, and common libraries and tools like zip and patch. Successful packing of Sage (by Gentoo, by Void, by Arch, by Conda) is packaging sagelib, and relying on the rest of the environment to provide what can be provided with a reasonable effort. Today I received a message from a Sage contributor urging to consider forking sagelib, even mentioning possible funding for such an effort, with the primary goal to make it easy to package by Linux et al. distros. I think a similar goal can be accomplished with less effort, e.g. by splitting the main Sage repo into sagelib and sage the distro. I hope there is still a room for consensus, before a "hostile" fork happens. And to pre-empt the question "but who will work on sage the distro", I can answer now: these who want to work on it. Don't force people who don't need it into working on it, just cause we have a monorepo, and only release it as a whole, and there won't be conflicts. E.g. you want to package in Sage the distro Python packages which use Rust (it's getting more and more popular) - fine, you can have fun doing it, but I wouldn't participate in it. E.g. you want to figure out the minimum numbers of packages you need from an old OS in order to build all of Sage - fine, but it should not slow down sagelib development, and should not be a consideration on how sagelib is developed (so e.g. dropping old Python versions should happen faster, it should not be dictated by the fact that a CI for this old OS and old python is already there). On 12 January 2024 21:00:15 GMT, Nils Bruin wrote: >On Wednesday 10 January 2024 at 16:59:22 UTC-5 Dima Pasechnik wrote: > >When it was discussed whether we wanted to use it, the main objection was >that it needs root (once, explicitly, to set up, then implicitly), thus >unsafe. >Conda was mentioned as a better option. But Conda is much bigger. > > >Conda is also multi-platform. A packaging of sagemath through conda is (or >at least should be) usable on both linux and OSX. Doesn't that make it a >more attractive target than homebrew? > >Also, why not package sage in multiple ways if there's a taste for it? Like >the packaging in linux distributions¸ it doesn't all need to be done by the >core sage team, but probably at least one or a few should be, to guarantee >that there's actually a way to get sage working for many people. As long as >someone volunteers to maintain a packaging method, what's the downside of >having it? > >If there are people to maintain both homebrew and conda, can't we just do >both? > >-- >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 view this discussion on the web visit >https://groups.google.com/d/msgid/sage-devel/adb84226-f0ca-4007-be6f-705ac0f59a9cn%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/44FC00CD-154C-43B5-AA83-04435D897B98%40gmail.com.
[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 Bruin wrote: > On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote: > > 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? > > I don't think it's desperately wrong. To sage, these structures look like: > > sage: P.construction() > (MPoly[z,q], Infinite polynomial ring in F over Rational Field) > sage: Q.construction() > (MPoly[z,q], Rational Field) > sage: parent(z*e).construction() > (MPoly[z,q], > Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q > over Rational Field) > > Note that an "infinite polynomial ring" is a different object than an > MPoly, and obviously it has different rules/priorities for finding common > overstructures. > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c48b5106-f62e-4141-ad5d-060d08d71c94n%40googlegroups.com.
[sage-devel] Re: Desparate for help
On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote: 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? I don't think it's desperately wrong. To sage, these structures look like: sage: P.construction() (MPoly[z,q], Infinite polynomial ring in F over Rational Field) sage: Q.construction() (MPoly[z,q], Rational Field) sage: parent(z*e).construction() (MPoly[z,q], Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q over Rational Field) Note that an "infinite polynomial ring" is a different object than an MPoly, and obviously it has different rules/priorities for finding common overstructures. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/de2e4b15-54d8-46e7-b10e-0e5eacd39aean%40googlegroups.com.
Re: [sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
On Wednesday 10 January 2024 at 16:59:22 UTC-5 Dima Pasechnik wrote: When it was discussed whether we wanted to use it, the main objection was that it needs root (once, explicitly, to set up, then implicitly), thus unsafe. Conda was mentioned as a better option. But Conda is much bigger. Conda is also multi-platform. A packaging of sagemath through conda is (or at least should be) usable on both linux and OSX. Doesn't that make it a more attractive target than homebrew? Also, why not package sage in multiple ways if there's a taste for it? Like the packaging in linux distributions¸ it doesn't all need to be done by the core sage team, but probably at least one or a few should be, to guarantee that there's actually a way to get sage working for many people. As long as someone volunteers to maintain a packaging method, what's the downside of having it? If there are people to maintain both homebrew and conda, can't we just do both? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/adb84226-f0ca-4007-be6f-705ac0f59a9cn%40googlegroups.com.
[sage-devel] Re: Regarding deprecation of a property
On Friday 12 January 2024 at 14:50:54 UTC-5 Ruchit Jagodara wrote: Okay, so I will make a new function named coefficient_monomials and will implement the functionality that Lorenz Panny suggested. Thank you for your help : ) . I think "coefficients_monomials" is a little clearer. ( coefficient_monomials could be interpreted as "monomials of the coefficient", which wouldn't make sense). -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ed37694f-3945-4b2e-adbb-255ca4cf2bf4n%40googlegroups.com.
Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages
On Fri, 2024-01-12 at 09:25 -0800, Niranjana K M wrote: > Should I have had started by cleaning the previous builds? It may be still > using old Cython spkg, built when it was sage 10.0 release. Because in venv > site-packages, it still says > sage/venv/lib64/python3.11/site-packages/Cython-0.29.32.dist-info. Very possibly. > What are the right sequence of commands to update an existing sagemath git > installation? I just did: Personally I run `git clean -x -f -d` before ./bootstrap to remove absolutely everything that isn't part of the repository. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/799606af358fb48cff6eeeca999a877c3e323ff3.camel%40orlitzky.com.
[sage-devel] Re: Regarding deprecation of a property
Okay, so I will make a new function named coefficient_monomials and will implement the functionality that Lorenz Panny suggested. Thank you for your help : ) . On Wednesday, January 10, 2024 at 8:16:25 PM UTC+5:30 Nils Bruin wrote: > On Wednesday 10 January 2024 at 03:03:09 UTC-8 Martin R wrote: > > ... What would be a good name? Brainstorming: `coefficient_system`, > `coefficients`, `coefficients_monomials`, > `coefficient_matrix_monomial_vector`... > > > I think coefficients_monomials() is the most descriptive, as it tells you > what you get back and in what order. > > C, m = PS.coefficients_monomials() > assert PolynomialSequence(C*m) == PS > > (incidentally, the assert also holds true with the return values of > coefficient_matrix) > > Also, thinking about whether C should be transposed: I think it's logical > that the rows of C are the coefficients of members of the sequence (since > matrices are closest to sequences of rows in sage), so C is already correct > in that sense. Therefore, m should indeed be a "column" vector, but sage is > ambivalent about whether vectors are rows or columns and therefore we can > safely return it as a vector. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/7e6e8093-da48-4d87-9f77-8bc931c3b4a3n%40googlegroups.com.
[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 Martin On Friday 12 January 2024 at 16:08:55 UTC+1 Martin R wrote: > 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 series > given implicitly by a list of equations. It works now for univariate > series, but it would be really cool if I could get to work also for > multivariate series and symmetric functions. See > https://github.com/sagemath/sage/pull/37033 > > Although it is not completely obvious that this will eventually work, it > is quite obvious that it won't work as long as we don't get sage to compose > polynomials correctly. > > Best wishes, > > 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2f4a84d9-6bac-47e7-bdb3-0b1e003fc340n%40googlegroups.com.
Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
On Friday, January 12, 2024 at 6:38:31 PM UTC+9 Martin R wrote: I just followed a few of the links Matthias posted today, and I must admit that I do not understand a word. That is normal. Just imagine that you are a passenger on a cruise and happened to enter to the engine room of the ship by accident. I guess that there are few developers who have adequate understanding of all disputed PRs (perhaps none except the authors) . That is why I think appointing one editor to resolve all disputed PRs is not a realistic idea. A group of editors would be better. But then why not give the right to all developers? For each of disputed PRs, there would be a few interested developers. I think majority voting by them is the way to go. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/78822461-092e-4a31-a3ed-075bc8e49ae2n%40googlegroups.com.
[sage-devel] Re: Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct
Here's a friendly overview on 9 of the "disputed" PRs, to help potential volunteer editors find PRs that match their interests -- in case the community decides that this model of appointing editors is the way to go. None of them has anything to do with "development philosophy", or with macOS; that's a false narrative. *A. Positively reviewed, but held back by demands by 1 participant:* https://github.com/sagemath/sage/pull/36561 "pkgs/sage-conf: Move metadata from setup.cfg to pyproject.toml" - Background reading: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ - "Needs review" set on Oct 28, 2023. - Positively reviewed by 1 reviewer on Nov 2, 2023. - Another participant demands that it must be changed so that when merged into his open PR, that PR will work without change. https://github.com/sagemath/sage/pull/36676 "Restructure sage.*.all for modularization, replace relative by absolute imports" - Background reading: https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#testing-distribution-packages - "Needs review" set on Nov 9, 2023. - Positively reviewed by 1 reviewer on Nov 15, 2023. - Another participant demands that it cannot be merged until the already documented design decision is reopened for a discussion. https://github.com/sagemath/sage/pull/36726 "CI Linux: Replace use of pkill" - Background reading: https://doc.sagemath.org/html/en/developer/portability_testing.html - "Needs review" set on Nov 15, 2023. - Positively reviewed by 3 reviewers, Nov 16 / Nov 23 / Dec 23, 2023 - *TW:* A senior developer uses frequent public displays of disrespect, makes false accusations, and makes insinuations about the intents of the PR author. *B. Stalled in "needs review" as author declines to address or respond to reviewer's comments* https://github.com/sagemath/sage/pull/36503 "Add config for ruff" https://github.com/sagemath/sage/pull/36489 "Use meson instead of configure for conda install" - PR author ends discussion with public display of disrespect. https://github.com/sagemath/sage/pull/36524 "Compile everything with meson" *C. PR declares original author's work as unimportant/illegitimate and removes/obstructs it* https://github.com/sagemath/sage/pull/36941 "Reduce number of systems test with minimal config" https://github.com/sagemath/sage/pull/36725 "Run ci-macos jobs in series" https://github.com/sagemath/sage/pull/36923 Revert "gh-36678: CI conda: Ignore baseline test failures " *D. *There are also Issues (not just PRs) marked as "disputed"; the search https://github.com/sagemath/sage/issues?q=sort%3Aupdated-desc+label%3Adisputed+ gives a broader picture of the problem of toxicity in our community. On Wednesday, January 10, 2024 at 6:50:10 AM UTC-8 William Stein wrote: > Dear Sage Developers, > > 1. There are over 20 pull requests labeled as "disputed" [1]. To > resolve these pull requests, we will be appointing an editor with no > direct involvement in the pull request to make a judgement call on > that particular pull request. We will then fully support the > decision of this editor. If you have the time to be the (possibly > anonymous) editor for a disputed pull request, please email us > (wst...@gmail.com, vbrau...@gmail.com) and we'll add your name to > our list. > > 2. There are numerous recent reports of violations of the code of > conduct to the sage-abuse mailing list. The code of conduct should > not be used as a tool in case you don't agree with somebody else. For > now, the main act of censure that the sage-abuse committee will be > taking going forward will be to delete comments (on github and mailing > lists) that violate the code of conduct. > > We do not have much time to devote to Sage development. However, we > both very much want things to move forward in a friendly and > encouraging way, and we would greatly appreciate it if the community > of Sage developers will support the above plan to move things forward > and ensure a positive experience for everyone participating in Sage > development. > > Best regards, > > Volker Braun and William Stein > > [1] > https://github.com/sagemath/sage/pulls?q=is%3Aopen+is%3Apr+label%3Adisputed > > -- > William (http://wstein.org) > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/35020662-a8c5-41c8-87be-cfbbb49e198cn%40googlegroups.com.
Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages
Should I have had started by cleaning the previous builds? It may be still using old Cython spkg, built when it was sage 10.0 release. Because in venv site-packages, it still says sage/venv/lib64/python3.11/site-packages/Cython-0.29.32.dist-info. What are the right sequence of commands to update an existing sagemath git installation? I just did: $ git fetch --all $ git pull --all $ git checkout master $ ./bootstrap $ ./configure --enable-system-site-packages --enable-fricas $ make -j2 On Friday, January 12, 2024 at 10:18:48 PM UTC+5:30 Michael Orlitzky wrote: > On Fri, 2024-01-12 at 08:33 -0500, Michael Orlitzky wrote: > > > > One thing I noticed is that you said "master" branch. Please try the > > "develop" branch instead -- that's where the actual development takes > > place. Both Sage and Gentoo are fast-moving and you'll have better luck > > with the latest code. > > I tried with "master" and did not hit this issue. Our systems are > otherwise very similar so that is discouraging, but doesn't necessarily > mean that "develop" won't work for you. I'll continue to poke at it. > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ecd62c54-fa20-47bf-b53f-090b732cc444n%40googlegroups.com.
Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages
On Fri, 2024-01-12 at 08:33 -0500, Michael Orlitzky wrote: > > One thing I noticed is that you said "master" branch. Please try the > "develop" branch instead -- that's where the actual development takes > place. Both Sage and Gentoo are fast-moving and you'll have better luck > with the latest code. I tried with "master" and did not hit this issue. Our systems are otherwise very similar so that is discouraging, but doesn't necessarily mean that "develop" won't work for you. I'll continue to poke at it. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/41211b7e8a717b12d253299103bb18e0d2f7e438.camel%40orlitzky.com.
[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 series given implicitly by a list of equations. It works now for univariate series, but it would be really cool if I could get to work also for multivariate series and symmetric functions. See https://github.com/sagemath/sage/pull/37033 Although it is not completely obvious that this will eventually work, it is quite obvious that it won't work as long as we don't get sage to compose polynomials correctly. Best wishes, 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 sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0bc36ade-2e0f-47f5-a259-57cc2d7c3734n%40googlegroups.com.
[sage-devel] Implementing minimum_generating_set() function
I am implementing the minimum_generating_set function in Sage, but I am facing some issues, such as where I should implement that function as my implementation uses some gap methods. And I found one class ParentLibGAP which can be used for this but I am not sure because I found that PermutationGroup class is not derived from this class so if I implement this function here then function will not be available for this group (And I don't know if there are many more), plus I have to use some functions of GroupMixinLibGAP class, so can you please suggest me a location or any fix for this. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d8050c58-a2b7-4745-aae6-4bc5217c6961n%40googlegroups.com.
Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages
On Fri, 2024-01-12 at 18:24 +0530, Niranjana K M wrote: > It is attached in the previous mail. > Indeed, sorry, it was my first email of the day. I have to get warmed up first. One thing I noticed is that you said "master" branch. Please try the "develop" branch instead -- that's where the actual development takes place. Both Sage and Gentoo are fast-moving and you'll have better luck with the latest code. (Does anyone actually use the master branch? Someone who wants to check out a release could just, like, check out the release. They're tagged. It's a silly pitfall.) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/85fc5dee1e753b9a70eb3ffdda58cec1f4e35c8c.camel%40orlitzky.com.
Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages
It is attached in the previous mail. On Fri, 12 Jan 2024, 5:09 pm Michael Orlitzky, wrote: > On Thu, 2024-01-11 at 20:56 -0800, Niranjana K M wrote: > > > > I am running on Gentoo Linux and sagemath is from git master branch. > > I am having system cython-3.0.6 built on python-3.11.7. > > > > Please help me to resolve it. > > > > Can you post your config.log? > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/c5cf266528f33850d3f1f4eac10e3c2e76c211b1.camel%40orlitzky.com > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAMcUJ1uNziO18_A7-87doMD9Sg9o-aaurwXAVsZ5OcQEeqJs%2BQ%40mail.gmail.com.
Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages
On Thu, 2024-01-11 at 20:56 -0800, Niranjana K M wrote: > > I am running on Gentoo Linux and sagemath is from git master branch. > I am having system cython-3.0.6 built on python-3.11.7. > > Please help me to resolve it. > Can you post your config.log? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c5cf266528f33850d3f1f4eac10e3c2e76c211b1.camel%40orlitzky.com.
Re: [sage-devel] That discussion about the Sage distribution etc.
On Fri, Jan 12, 2024 at 11:01 AM Dima Pasechnik wrote: > > From my perspective, throughout these discussions there is a strong > push against slimming Sage down by removing these unneeded packages > coming from Matthias, often coupled with responses by him (on > trac/github) I consider rude and disrespectful of other's opinions. > > See e.g. https://github.com/sagemath/sage/issues/32532 > You can see how I am subjected to gaslighting by Matthias there. > (Let's do this/no, stop, don't/just drop this/-1 (without > explaining/... coming up in cycles). > Description of this issues/32532 was edited in a questionable way by > Matthias recently. PS. Needless to say, the need for gcc/gfortran in bundled in Sage is really not there, since years and years. On macOS one has gfortran from Homebrew, and the argument that Homebrew is "insecure" doesn't really fly any more, as Homebrew packages are nowadays notarized/signed, etc etc. > > > > > On Fri, Jan 12, 2024 at 7:43 AM Matthias Koeppe > wrote: > > > > Here's a quick overview on the discussions on this topic since 2021. > > > > (I collected most of this recently in the Issue description of > > https://github.com/sagemath/sage/issues/32532). > > > > sage-devel: proposal - remove gcc, gfortran, python building/spkgs (June > > 2021) > > > > Resulted in implementing configure: Change defaults to > > --with-system-gcc=force, defer error exits after system package info is > > shown #32060 > > No clear support for removing anything without replacement. > > Some talk about conda, no action. > > > > sage-devel: #32532 - removing gcc and gfortran spkgs (September 2021) > > > > No clear support for anything. > > Some talk about conda, no action. > > > > sage-devel: Re: [sage-release] Sage 10.0.rc0 released (Apr 2023) (TW: > > abusive comments) > > > > sage-devel: What was/is/will be the purpose of maintaining the Sage > > distribution? (Apr 2023) > > > > Again talk about conda > > Resulted in opening PR Install some dummy and optional packages using > > conda-forge (micromamba) #35585; no reaction > > > > sage-devel: Policy for disputed PRs: discussion (Nov 2023). > > > > CI Linux: Replace use of pkill #36726 (Nov–Dec 2023) (TW: abusive comments) > > > > > > Pointers to related discussions and facts: > > > > On the git repository structure (monorepo / multirepo): > > https://groups.google.com/g/sage-devel/c/AaKxoNQAWMg/m/uY1rW5n0BQAJ > > (October 2021), https://github.com/sagemath/sage/pull/36777 (December 2023). > > > > On what systems we support building Sage from source: > > https://github.com/sagemath/sage/issues/32074 > > > > What versions of Python we are supporting; including a discussion of > > maintenance costs: > > https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy > > > > > > -- > > 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 view this discussion on the web visit > > https://groups.google.com/d/msgid/sage-devel/87c9218a-9b6b-4fb9-8f35-78624ba67054n%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq05ZenM9OwSsj1v_yF7Nak9dN%2Bf83hW%2BC75UeYwNvxUyw%40mail.gmail.com.
Re: [sage-devel] That discussion about the Sage distribution etc.
>From my perspective, throughout these discussions there is a strong push against slimming Sage down by removing these unneeded packages coming from Matthias, often coupled with responses by him (on trac/github) I consider rude and disrespectful of other's opinions. See e.g. https://github.com/sagemath/sage/issues/32532 You can see how I am subjected to gaslighting by Matthias there. (Let's do this/no, stop, don't/just drop this/-1 (without explaining/... coming up in cycles). Description of this issues/32532 was edited in a questionable way by Matthias recently. On Fri, Jan 12, 2024 at 7:43 AM Matthias Koeppe wrote: > > Here's a quick overview on the discussions on this topic since 2021. > > (I collected most of this recently in the Issue description of > https://github.com/sagemath/sage/issues/32532). > > sage-devel: proposal - remove gcc, gfortran, python building/spkgs (June 2021) > > Resulted in implementing configure: Change defaults to > --with-system-gcc=force, defer error exits after system package info is shown > #32060 > No clear support for removing anything without replacement. > Some talk about conda, no action. > > sage-devel: #32532 - removing gcc and gfortran spkgs (September 2021) > > No clear support for anything. > Some talk about conda, no action. > > sage-devel: Re: [sage-release] Sage 10.0.rc0 released (Apr 2023) (TW: abusive > comments) > > sage-devel: What was/is/will be the purpose of maintaining the Sage > distribution? (Apr 2023) > > Again talk about conda > Resulted in opening PR Install some dummy and optional packages using > conda-forge (micromamba) #35585; no reaction > > sage-devel: Policy for disputed PRs: discussion (Nov 2023). > > CI Linux: Replace use of pkill #36726 (Nov–Dec 2023) (TW: abusive comments) > > > Pointers to related discussions and facts: > > On the git repository structure (monorepo / multirepo): > https://groups.google.com/g/sage-devel/c/AaKxoNQAWMg/m/uY1rW5n0BQAJ (October > 2021), https://github.com/sagemath/sage/pull/36777 (December 2023). > > On what systems we support building Sage from source: > https://github.com/sagemath/sage/issues/32074 > > What versions of Python we are supporting; including a discussion of > maintenance costs: > https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/87c9218a-9b6b-4fb9-8f35-78624ba67054n%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1%3DXMzzrfJcHfRgmD1yHCZ2xyO%3DJAbvH%3DZPQVFHNaivFA%40mail.gmail.com.
[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 Polynomial Ring in FESDUMMY_1, FESDUMMY_0 over Rational Field ipdb> p c.polynomial().parent() is R False ipdb> p R(c.polynomial()).parent() is R True -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ffa9edbc-4272-4c90-90f7-69c020bd68b9n%40googlegroups.com.
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 end-user-centric way of looking at it is also valid. It seems to me that "developer" here refers to a very different kind of developer than me, which is probably because I mostly care about getting my mathematics done and (probably because of that) use only linux. I never had any severe build problems, although recently I have had some problems with TMPDIR. I therefore wonder whether the outcome of the dispute might affect me, and if so, how - other than socially, which would be probably the most important thing anyway. I am unable to answer the former question (i.e., would it affect me technically) by looking at the collection of links. As an example: the introduction of the `# needs something` comments did affect me, and I don't see the benefit yet, but it is only a very minor annoyance, so I certainly won't argue, assuming that at least somebody is convinced that it's a good thing. Best wishes, Martin On Thursday 11 January 2024 at 14:32:51 UTC+1 kcrisman wrote: > Many of these are disputed for the same underlying reasons. Appointing > a different editor for each PR is not likely to help. If you pick an > editor from Camp A, he or she will always rule in favor of Camp A; pick > an editor from Camp B... > > > The camps are roughly split across the question whether > Sage the distro should be deemphasized, and the development > process should be centered around sagelib, or not. > > As well, and it's not a coincidence, roughly the same partition > is on the basis of the developer platform used by the camp member. > It appears that the Linux users are primarily for deemphasizing > Sage the distro, and macOS user are primarily against. > > > As a general observation, this seems somewhat accurate. That said, as > Martin R points out, many (most?) people don't seem to be in a "Camp". > > > I suspect it's due to the latter used to Sage the distro as a "missing > macOS > package manager". > So they are happy adding more and more spkgs to Sage. > And Linux users rightly see adding to Sage spkgs, which > package software available on their systems in a regular way, > as a bloat, which moreover needs constant attention - > while sagelib suffers. > > I don't think that without solving this conflict the disputed PRs > dispute can be solved. > > I may go on discussing how the Sage macOS problems may be > mitigated, but not here and now. > > > > 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 end-user-centric way of looking at it is also valid. And these > are largely using Sage on Mac (without knowing about things like brew or > conda, nor really wanting to) or even Windows (where not even these options > exist, but people seem content to download whatever older version still is > available - and they do). Let's ignore the cloud solutions available for > now, since I still suspect that for "ordinary" solo uses this is not as > significant a factor (as opposed to collaborative ones). > > So somewhere on sage-devel (probably not this thread) it would be really > helpful for people *other* than the two or four primary "representatives" > of Camps A and B to explain the vision of Camps A and B regarding both > developers and end users. Because the developer time/bloat issue is real, > and the end user not being able to use Sage issue is real (on Windows, at > the very least, and it was nearly the case on Mac). > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ca61d246-0d99-4912-8c15-518de90d254an%40googlegroups.com.
