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

much cheaper. Dima > >Martin >On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote: > >> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote: >> >> How about using something like https://github.com/NeilGirdhar/extended_int >> ? >>

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

ple's input as this > is not code I am familiar with using and so I don't know what people could > be relying on. > > On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote: > >> > >> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin wrote: > >

Re: [sage-devel] Re: VOTE: use "blocker" label only for PRs; use "critical" label for Issues

On Wed, Feb 28, 2024 at 4:46 PM William Stein wrote: > > > On Wed, Feb 28, 2024 at 8:39 AM Eric Gourgoulhon > wrote: > >> -1 from my side, for I think an issue can be a blocker. >> For instance: >> https://github.com/sagemath/sage/issues/36914 >> This issue, which regards the use of the notebook

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

h Shree >>>>>> wrote: >>>>>> >>>>>>> Thank you for reminding >>>>>>> I went through. >>>>>>> We need to Decompose A11 only and rest can be calculated via taking >>>>>>> inverse

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

On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin wrote: > On Wednesday 28 February 2024 at 08:03:45 UTC-8 Giacomo Pope wrote: > > > I don't know the history of this choice or what we should be doing > generally. -1 for polynomials with only positive degree seems like a > computer science workaround, bu

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

On Wed, Feb 28, 2024 at 11:29 AM Giacomo Pope wrote: > Apologies for the basic question in this thread, but recently I have seen > lots of conversation about the different labels and I want to clarify > something for myself. > > In the past few PR I have made for Sage, randomised testing has unco

Re: [sage-devel] VOTE: use "blocker" label only for PRs; use "critical" label for Issues

On Wed, Feb 28, 2024 at 6:45 AM Kwankyu Lee wrote: > Hi, > > Here I withdraw the early premature "giving up" on my recent proposal, > since afterwards there were some positive comments. Hence I open a voting > for > > Proposal: > > 1. Do not use "blocker" label for Issues, as "blocker" means to d

Re: [sage-devel] Looking for volunteers

On Wed, Feb 28, 2024 at 3:20 AM David Roe wrote: > Hi Sage developers, > As some of you may be aware, there has been more conflict in the last > several months than normal, including multiple violations of our Code of > Conduct. Sage's mechanism for moderating conflicts and addressing such > vio

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

arately instead of single row permutation which sage >>>> usage generally for plu decomposition. >>>> User will have to manage row and col permutations. >>>> or else >>>> We can return handler function for reconstruction of matrix from L, U >>>> &am

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

in the polynomial case, the usual convention is deg(0)=-infinity I don't know why Sage uses -1 instead: R.=QQ[] f=0*x*y f.degree() gives -1. On Wed, Feb 28, 2024 at 1:50 PM 'Martin R' via sage-devel < sage-devel@googlegroups.com> wrote: > Sorry, I confused it with valuation, but I guess it is st

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

#x27;s called "whataboutism". Invoking what you consider inappropriate >behavior by others is not relevant. Please stay on topic, and please follow >Sage's code of conduct in your posts. > >On Tuesday, February 27, 2024 at 1:01:25 PM UTC-8 Dima Pasechnik wrote: > >&g

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

t is not a personal attack? Of course it is. > >On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote: > >> >> >> On 27 February 2024 19:37:31 GMT, Matthias Koeppe >> wrote: >> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Pal

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 27 February 2024 20:21:26 GMT, Nils Bruin wrote: >On Tuesday 27 February 2024 at 10:50:55 UTC-8 John H Palmieri wrote: > > >As Nathan points out, this will likely lead to instability. Someone will >upgrade some component, and most of the time that will be fine, but >occasionally it will br

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 27 February 2024 19:37:31 GMT, Matthias Koeppe wrote: >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote: > >A pretty safe second choice would be to have "make download" also download >the relevant files for pip installation and tell pip where to find them. If >we i

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 27 February 2024 18:50:55 GMT, John H Palmieri wrote: >Regarding the proposal to allow standard packages to be pip packages, no >one really knows how much people rely on the all-in-one tarball that we >currently distribute. No one really knows how often the "make download" >option is use

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

0s. Because if we pad then how will they affect the outputs, so that >we can extract p,l,u for unpadded matrix. please read details I wrote on how to deal with the non-square case. There is no padding needed. > >On Tuesday, February 27, 2024 at 10:03:25 PM UTC+5:30 Dima Pasechnik wrote:

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

t;[1.0 2.0] >[0.0 1.0] > > >Shall I continue with this? sure, you are quite close to getting it all done it seems. >On Tuesday, February 6, 2024 at 11:29:07 PM UTC+5:30 Dima Pasechnik wrote: > >> Non-square case for LU is in fact easy. Note that if you have A=LU as >> a

Re: [sage-devel] Re: Unload "blocker" label

On Mon, Feb 26, 2024 at 9:59 PM Matthias Koeppe wrote: > On Monday, February 26, 2024 at 9:43:18 AM UTC-8 Vincent Delecroix wrote: > > let me do a proposal. > > Introduce a new label distinct from "blocker" for > > usage 2: PRs that should be merged temporarily before CI tests run > > > For refer

Re: [sage-devel] Re: Can't compile version 10.2

it's an auto-generated file, to build the interfaces to all the Pari's functions - and there are a lot of them. On 26 February 2024 16:00:40 GMT, Topaze Topaze wrote: >Oh, sorry... it seems that a *single* file takes a surprisingly long time >to compile (about 30 minutes !) Please forget my req

Re: [sage-devel] Re: Unload "blocker" label

On Mon, Feb 26, 2024 at 12:45 PM Emmanuel Charpentier < emanuel.charpent...@gmail.com> wrote: > > > Le lundi 26 février 2024 à 12:59:47 UTC+1, Dima Pasechnik a écrit : > > [ Snip... ] > > Are you saying that only PRs can block a release? > > But how does one

Re: [sage-devel] Re: Unload "blocker" label

On Mon, Feb 26, 2024 at 11:36 AM Kwankyu Lee wrote: > On Monday, February 26, 2024 at 6:49:35 PM UTC+9 Dima Pasechnik wrote: > > >usage 3: Issues that should be fixed as fast as possible > > > >To me it is rather "issues that should be fixed before the next > &

Re: [sage-devel] Re: Unload "blocker" label

On 26 February 2024 09:08:08 GMT, Vincent Delecroix <20100.delecr...@gmail.com> wrote: >Hi Kwankyu, > >I do not agree with > >usage 3: Issues that should be fixed as fast as possible > >To me it is rather "issues that should be fixed before the next >release" (or at least it was the way it was

Re: [sage-devel] Re: int vs long in cython

On Sun, Feb 25, 2024 at 9:48 AM Travis Scrimshaw wrote: > Sorry for the delayed response. > > If the C compiler can't tell the difference between an int and a long, > then that suggests that there is still a difference. I am not sure that > Cython has any specification that these are different. M

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

8 UTC+1, Nils Bruin a écrit : > > On Thursday 15 February 2024 at 17:02:14 UTC-8 Dima Pasechnik wrote: > > but that's sphinx (Python), not jupyter. > > I see. The page I linked to is from Jupyter{book} which is, despite the > similarity in name, not the jupyter notebook se

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 20 February 2024 22:44:02 GMT, Matthias Koeppe wrote: >On Tuesday, February 20, 2024 at 12:45:25 PM UTC-8 Dima Pasechnik wrote: > >On Tue, Feb 20, 2024 at 8:13 PM Matthias Koeppe >wrote: > >I have been doing the vast majority of this maintenance work in the past 4

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Tue, Feb 20, 2024 at 8:13 PM Matthias Koeppe wrote: > On Tuesday, February 20, 2024 at 11:43:07 AM UTC-8 Dima Pasechnik wrote: > > On 20 February 2024 17:28:31 GMT, Matthias Koeppe > wrote: > >On Tuesday, February 20, 2024 at 1:43:27 AM UTC-8 Dima Pasechnik wrote

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 20 February 2024 17:28:31 GMT, Matthias Koeppe wrote: >On Tuesday, February 20, 2024 at 1:43:27 AM UTC-8 Dima Pasechnik wrote: > >The number of dependencies has grown to the point it has gotten too hard to >maintain, > > >No. It's easier than it has ever been

Re: [sage-devel] Need advice on PR attempting to modify coercion for Python int type

Did you try running tests locally? Our CI sometimes acts up On 20 February 2024 12:49:03 GMT, Giacomo Pope wrote: >Hey all, > >I have been trying to work on a fix for scalar multiplication of points on >elliptic curves over finite fields. The issue at the moment is that when we >multiply by a

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 20 February 2024 01:57:40 GMT, Nathan Dunfield wrote: >On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote, >responding to Dima: > >You said: "The difference between wheel packages vs pip packages is that >the latter don't require pre-fetched wheels, and absence of the n

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

On Mon, Feb 19, 2024 at 9:20 PM seb@gmail.com wrote: > > *Is it time for the next step with syncing status labels > (https://github.com/sagemath/sage/issues/35927 > )? * > > The reason this is blocked is because there is a bug in the GitHub web

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

contents. >>> >>> *Proposed action items: * >>> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so >>> that "git clone" is described as the primary way to obtain the Sage >>> sources. That the big release tarball is availa

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 19 February 2024 21:08:54 GMT, John H Palmieri wrote: > > >On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote: > >On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote: > >This (A and B below) has the advantage of being quite explicit. The &g

Re: [sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On Mon, Feb 19, 2024 at 8:27 PM Matthias Koeppe wrote: > On Monday, February 19, 2024 at 11:51:46 AM UTC-8 Dima Pasechnik wrote: > > The purpose of "install-requires.txt" is rather unclear, especially in > presence > of "package-version.txt". What is it

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

installation-steps) >> for the limited no-internet connectivity use case. >> >> *B. *Likewise, get rid of all of these "Download Sage source code" pages >> (https://www.sagemath.org/download-source.html, >> https://www.sagemath.org/download-latest.html), mirro

Re: [sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On Mon, Feb 19, 2024 at 7:34 PM Matthias Koeppe wrote: > On Monday, February 19, 2024 at 10:35:45 AM UTC-8 Dima Pasechnik wrote: > > On Mon, Feb 19, 2024 at 5:31 PM Matthias Koeppe <https://groups.google.com/>> wrote: > > On Monday, February 19, 2024 at 5:47:46 AM UTC

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Mon, Feb 19, 2024 at 5:16 PM Matthias Koeppe wrote: > On Monday, February 19, 2024 at 5:42:08 AM UTC-8 tobia...@gmx.de wrote: > > This discussion about the need to fix the version of pytest *and its > runtime dependencies* is almost comical. > > > No, you are in the wrong thread. > > This thre

Re: [sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

cit declaration of the runtime >> dependencies. >> >> >> >> On Saturday, February 17, 2024 at 4:51:45 PM UTC+8 Dima Pasechnik wrote: >> >>> I have made it clear under what condition you can count my vote as +1. >>> >>> To make it clear: i

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Sun, Feb 18, 2024 at 6:57 PM Nathan Dunfield wrote: > On Sunday, February 18, 2024 at 12:14:58 PM UTC-6 Dima Pasechnik wrote: > > Reading: > https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types > > > The wheel you talk about is j

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Sun, Feb 18, 2024 at 6:09 PM Matthias Koeppe wrote: > On Sunday, February 18, 2024 at 10:05:21 AM UTC-8 Dima Pasechnik wrote: > > On Sun, Feb 18, 2024 at 5:24 PM Matthias Koeppe > wrote: > > On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote: > > 1)

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Sun, Feb 18, 2024 at 5:15 PM Matthias Koeppe wrote: > On Sunday, February 18, 2024 at 4:40:35 AM UTC-8 Dima Pasechnik wrote: > > On 17 February 2024 23:31:43 GMT, Matthias Koeppe > wrote: > >On Saturday, February 17, 2024 at 3:04:49 PM UTC-8 Nathan Dunfield wrote: &g

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Sun, Feb 18, 2024 at 5:24 PM Matthias Koeppe wrote: > On Sunday, February 18, 2024 at 9:07:04 AM UTC-8 Dima Pasechnik wrote: > > 1) you can even just get a binary wheel of pytest installed - it is very > fast, and robust. > > > Yes, that's what my PR https://git

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 18 February 2024 15:51:27 GMT, Nathan Dunfield wrote: >On Sunday, February 18, 2024 at 6:26:28 AM UTC-6 Dima Pasechnik wrote: > >I cannot imagine CI breaking down by, say, pytest. > > >I can definitely see that happening, and indeed it seems to have done so >for oth

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 17 February 2024 23:31:43 GMT, Matthias Koeppe wrote: >On Saturday, February 17, 2024 at 3:04:49 PM UTC-8 Nathan Dunfield wrote: > >It seems to me that the "wheel" type Sage packages, each of which is >primarily just the version number of a file on PyPI and its hash, is like a >"requireme

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 17 February 2024 23:04:49 GMT, Nathan Dunfield wrote: >On Saturday, February 17, 2024 at 1:13:33 PM UTC-6 Dima Pasechnik wrote: > >My proposal is in fact aimed at reducing the number of pinned Sage >dependecies, drastically. > >Because most of them are either dependen

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 17 February 2024 17:16:07 GMT, Matthias Koeppe wrote: >On Saturday, February 17, 2024 at 7:06:27 AM UTC-8 Nathan Dunfield wrote: > >On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote: > >If one does not care about the use case without internet access, then it's >just t

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 17 February 2024 15:01:14 GMT, Kwankyu Lee wrote: > > >there are ways to use pip without internet, with the necessary wheels >pre-fetched. >That's what Sage does with wheel packages. > > >Yes. This is a sage package of source type "wheel", as Matthias explained. > > >The difference betwee

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 17 February 2024 02:26:32 GMT, Kwankyu Lee wrote: > > > > >By default the package content would be fetched, as pip does, > > >Not just as pip does, but by actually calling "pip" to contact PyPI. > > >and that would mean the default configuration for sage would require >internet at install

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 17 February 2024 02:26:32 GMT, Kwankyu Lee wrote: > > > > >By default the package content would be fetched, as pip does, > > >Not just as pip does, but by actually calling "pip" to contact PyPI. > > >and that would mean the default configuration for sage would require >internet at install

Re: [sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

ent-1820148873 on >the emergence of this idea. > >On Friday, February 16, 2024 at 4:34:12 PM UTC-8 Dima Pasechnik wrote: > >> >> >> On 16 February 2024 23:33:48 GMT, Matthias Koeppe >> wrote: >> >On Friday, February 16, 2024 at 1:25:13 PM UTC-8 Dima Pasechn

Re: [sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On 16 February 2024 23:33:48 GMT, Matthias Koeppe wrote: >On Friday, February 16, 2024 at 1:25:13 PM UTC-8 Dima Pasechnik wrote: > >>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote: >My vote for is conditional on them remaining pip packages, and that&#x

Re: [sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On 16 February 2024 20:05:51 GMT, Matthias Koeppe wrote: >On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote: > >It seems you had one vote for, and one against. Is it enough to declare >these packages accepted as standard now? > > >We haven't coun

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

r your support! > > Martin > > On Friday 16 February 2024 at 20:18:42 UTC+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

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

ble. ┃ > ┗┛ > sage: default_sdp_solver("SCIP") > > --- > ValueErrorTraceback (most recent call > last) > > ... > > > On Friday 16 February 2024 at 18:33:

[sage-devel] Re: Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

It seems you had one vote for, and one against. Is it enough to declare these packages accepted as standard now? By the way, pytest inclusion already adds 5 standard packages, not one. On Friday, February 16, 2024 at 5:24:57 PM UTC Matthias Koeppe wrote: > Open for review: > - https://github.c

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

But you can be lucky with the binary wheel you can get from PyPI. I didn't test it though, but perhaps it will just work. On Friday, February 16, 2024 at 4:55:21 PM UTC Matthias Koeppe wrote: > As noted in > https://github.com/sagemath/sage/wiki/Sage-10.2-Release-Tour#known-problems-and-workaro

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

Try ./sage --pip install pyscipopt it appears they have a newer version now, 4.4.0. HTH Dima On Friday, February 16, 2024 at 3:48:09 PM UTC Martin R wrote: > I (urgently) need the scip MILP solver (on 10.3.beta8, Ubuntu 22.04). > > sage -i pyscipopt > > ends with > >

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

On Thu, Feb 15, 2024 at 11:56 PM Nils Bruin wrote: > On Thursday 15 February 2024 at 13:19:47 UTC-8 Michael Orlitzky wrote: > > > The notebook release process minifies all of its javascript code. The > bit that sets the MathJax options is in there somewhere but good luck > finding it. > > Well, t

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

On Thursday, February 15, 2024 at 9:30:10 AM UTC-8 Eric Gourgoulhon wrote: > >> Le jeudi 15 février 2024 à 13:36:46 UTC+1, Dima Pasechnik a écrit : >> >> A possible solution does not involve changing Sage/Jupyter config. It's >> by capturing http requests to CDN and

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

A possible solution does not involve changing Sage/Jupyter config. It's by capturing http requests to CDN and replacing them with the local resources. See e.g. https://discourse.jupyter.org/t/running-voila-without-internet/13823/3 where this is proposed for another MathJax-dependent project.

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

On 15 February 2024 10:20:39 GMT, Kwankyu Lee wrote: > > >With the previous version of Jupyterlab shipped with Sage 10.2, the >system's MathJax was used. > >Can't we tweak the new Jupyterlab shipped with Sage 10.3 to use the >system's MathJax as well? > > >We don't do that. Perhaps tweaking

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

On 15 February 2024 09:18:06 GMT, Eric Gourgoulhon wrote: >Le jeudi 15 février 2024 à 04:54:42 UTC+1, Kwankyu Lee a écrit : > > >I checked again on mac. Yes, jupyterlab (and notebook 7 as well) of Sage >10.3.beta8 fails in loading mathjax 2.7.7. (Before it worked because of the >cache, I gue

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

I've filed https://sourceforge.net/p/maxima/bugs/4262/ On Wed, Feb 14, 2024 at 7:14 PM Dima Pasechnik wrote: > > > On Wed, Feb 14, 2024 at 6:12 PM Oscar Benjamin > wrote: > >> Maxima's simplify_sum function produces something similar looking: >> >>

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

does try something more clever - but fails. Dima > > -- > Oscar > > On Wed, 14 Feb 2024 at 17:52, Dima Pasechnik wrote: > > > > It appears to come from Maxima, but I have trouble reproducing this in > Maxima. > > Perhaps it's a bug in the Maxima interf

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

It appears to come from Maxima, but I have trouble reproducing this in Maxima. Perhaps it's a bug in the Maxima interface? Is there a direct way to see how Maxima is called in this instance? Dima On Mon, Feb 12, 2024 at 2:53 PM Georgi Guninski wrote: > There is discussion about this on mathove

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

That's why we should just stop shipping jupyterlab, and instead use one offered by the OS or some other standard Jupyter way. Here we are trying to solve already solved problems, what's the point of it? On 14 February 2024 14:39:05 GMT, Kwankyu Lee wrote: > > >On Wednesday, February 14, 2024

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

For off the grid working with MathJax, you need it locally installed. It might be that by default it doesn't happen, and MathJax is dynamically loaded from the net. On 14 February 2024 12:47:52 GMT, Eric Gourgoulhon wrote: >Hi, > >While working on a Sage 10.3.beta notebook in a train withou

Re: [sage-devel] meson_python build failure: missing tar.gz on sage github?

On Tue, Feb 13, 2024 at 8:52 AM Janmenjaya Panda wrote: > Hello, > I got the following error while (running 'make') building sage from the > forked repo of the source code (This branch (develop) is up to date with > sagemath/sage:develop). > > [meson_python-0.15.0] Thread model: posix > [meson_py

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

On 13 February 2024 00:58:04 GMT, Nils Bruin wrote: >On Monday 12 February 2024 at 15:58:11 UTC-8 Dima Pasechnik wrote: > >What's rotten and decaying - well, the most obvious points are: > >* pynac (memory leaks, bugs, sketchy or no docs, authors left long time >

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

ty use case. > > B. Likewise, get rid of all of these "Download Sage source code" pages > (https://www.sagemath.org/download-source.html, > https://www.sagemath.org/download-latest.html), mirror selection, etc. from > the Sage website. > > > On Sunday, February 11,

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

ng things. > > On Thu, 8 Feb 2024 at 14:02, Michael Orlitzky wrote: > > > > On Thu, 2024-02-08 at 11:30 +, Dima Pasechnik wrote: > > > > > > We should not try to compete, in effect, with Conda etc, yet we do. This > > > is > > > the primar

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Mon, Feb 12, 2024 at 10:01 PM Matthias Koeppe wrote: > > On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote: > > requirements.txt might as well specify the range, and this is used too e.g. > > build/pkgs/phitigra/requirements.txt has > phitigra>=0.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Mon, Feb 12, 2024 at 10:11 PM Matthias Koeppe wrote: > > On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote: > > > 2. Also the large Sage source tarball does not "vendor". It is a shipment > > of a distribution. Distributions do

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Mon, Feb 12, 2024 at 6:02 PM Matthias Koeppe wrote: > > On Monday, February 12, 2024 at 3:18:05 AM UTC-8 Dima Pasechnik wrote: > > > Pinning packages to a set of tested working versions is a standard practice, and as a matter of fact part of best practices to achieve stabi

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

On Mon, Feb 12, 2024 at 6:06 PM David Lowry-Duda wrote: > > On 22:42 Sun 11 Feb 2024, Matthias Koeppe wrote: > >*2. Is our community aware of the sagemath/sage GitHub wiki?* > >https://github.com/sagemath/sage/wiki > >- Are the contents of the wiki front page useful? > > I think the existence of t

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Mon, Feb 12, 2024 at 12:34 PM kcrisman wrote: > > As part of this thread, I'd again ask for a discussion of the following > situation I asked in the other thread. Dima had some interesting points > about a less-vendored approach saving disk space etc., but it would be > helpful to have inpu

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On Mon, Feb 12, 2024 at 12:57 AM Matthias Koeppe wrote: > > On Sunday, February 11, 2024 at 3:34:46 PM UTC-8 Dima Pasechnik wrote: > > On 11 February 2024 22:47:24 GMT, Matthias Koeppe > wrote: > >On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

On 11 February 2024 22:47:24 GMT, Matthias Koeppe wrote: >On Sunday, February 11, 2024 at 1:46:40 PM UTC-8 Matthias Koeppe wrote: > >I'll make an attempt to quantify this cost > > >Here's an illustration of the workflow for making python_build a standard >"wheel" package, as proposed in >htt

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

building or upgrading. When new versions >of "pip" packages add dependencies that happen to be Sage packages, there >is a separate source of instability. OTOH a package like pytest or tox is basically an external tool, and using an appropriate version of it is all what's needed.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

are automatically provided by GitHub on releases (and tags) >would be sufficient. (They do not contain upstream; but they also do not >contain the helpful .git directory that our tarball release script >painstakingly adds.) > >On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechni

[sage-devel] [Proposal] allow standard packages to be pip packages, reduce source tarball size

Currently the standard packages cannot be pip packages, i.e. we must, in effect, vendor them. This entails an extra effort which is often not needed, in particular as we patch only very few Python packages. Pip packages are on the other hand installed straight from PyPI. Good examples of standa

Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On 11 February 2024 15:34:18 GMT, mmarco wrote: >Maybe you can get the best of both worlds? I mean: use those packages as >pip packages, but also have a way to download a big tarball with those >packages, and then pip-install them from that local copy? > >El domingo, 11 de febrero de 2024 a l

Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

5 On 11 February 2024 13:21:46 GMT, kcrisman wrote: > > >I believe I'm the person who introduced that long standing policy. It >was indeed motivated by a significant paying customer's requirement >to install Sage entirely from source, and without an external network. >I believe no such custo

Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On 10 February 2024 23:40:59 GMT, Matthias Koeppe wrote: >On Saturday, February 10, 2024 at 2:56:57 PM UTC-8 Dima Pasechnik wrote: > >yes, make them standard, but keep them pip packages (i.e. no version >pinning, no tarballs/checksums). > > >By current policy, "st

Re: [sage-devel] Proposal: Make pytest, pytest_xdist, pytest_mock, python_build standard packages

On Sat, Feb 10, 2024 at 10:18 PM Matthias Koeppe wrote: > > We added the packages as optional "pip" packages (see > https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types > for the terminology), each more than 1 year ago. > > - > https://deploy-livedoc--sagemath.

Re: [sage-devel] Re: Installing sagemath on macOS

macOS headers. >On Monday, February 5, 2024 at 4:58:36 PM UTC-6 Sai Chandhrasekhar wrote: > >> On Monday, February 5, 2024 at 4:48:08 PM UTC-6 Dima Pasechnik wrote: >> >>> >>> >>> On 5 February 2024 21:58:54 GMT, "dan...@gmail.com" >&g

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

-square matrices this seems a bit more complicated, but, well, still doable. HTH Dima On Mon, Feb 5, 2024 at 6:00 PM Nils Bruin wrote: > > On Monday 5 February 2024 at 02:31:04 UTC-8 Dima Pasechnik wrote: > > > it is the matter of adding extra zero rows or columns to the matrix

Re: [sage-devel] Re: Installing sagemath on macOS

On 5 February 2024 21:58:54 GMT, "dan...@gmail.com" wrote: >You could just use Sage_macOS >, quick and >easy! for Sage development, you need a source install. > >On Monday, February 5, 2024 at 3:49:02 PM UTC-6 Matthias Koeppe wr

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

On 5 February 2024 06:30:45 GMT, 'Animesh Shree' via sage-devel wrote: >The other library that scipy uses is SuperLU : >https://portal.nersc.gov/project/sparse/superlu/ >for the function scipy.sparse.linalg.splu : >https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.splu

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

ng opaque C >objects I will go through it check out the source code of cvxopt. >On Tuesday, January 30, 2024 at 8:58:43 PM UTC+5:30 Dima Pasechnik wrote: > >> IMHO opaque C objects may be accessed from Python, it just needs an >> implementation >> >> >> O

Re: [sage-devel] Re: Implementing minimum_generating_set() function

>>>> sage: N = p.minimal_normal_subgroups()[0] >>>>> sage: N >>>>> Subgroup generated by [(2,5)(3,6)(4,7)] of (Permutation Group with >>>>> generators [(2,3,4,5,6,7)]) >>>>> sage: N.list() >>>>&

Re: [sage-devel] Re: Failure to build sage 10.2 with first pkg gcc-12.2.0

you probably want to set FC to point to gfortran-13 too. On 2 February 2024 18:24:29 GMT, Randall Rathbun wrote: >Thank you very much for that sharp-eyed catch. The /usr/bin/python was >indeed symlinked to ipython. >I did update the CC and CXX flags also to point to version 13 which is >instal

Re: [sage-devel] Failure to build sage 10.2 with first pkg gcc-12.2.0

openSUSE Leap 15.5 should let you install sufficiently fresh gcc/g++/gfortran packages, so that you don't need to build them from scratch. (I also doubt if it's at all possible to build gcc 12.2 with gcc 7.5 - you have the latter). On Fri, Feb 2, 2024 at 5:52 PM Randall Rathbun wrote: > > I dow

Re: [sage-devel] Efficiency of Groebner basis for constraints of the form $(a_i x_i+b_i)(a_j x_j+b_j)=0$

On Thu, Feb 1, 2024 at 5:04 AM Georgi Guninski wrote: > > On Wed, Jan 31, 2024 at 10:54 PM Dima Pasechnik wrote: > > > > Do you have exactly one (or at most) relation for any pair of variables? > > Can one have i=j ? > > > > Or it's the notation which

Re: [sage-devel] Efficiency of Groebner basis for constraints of the form $(a_i x_i+b_i)(a_j x_j+b_j)=0$

On 31 January 2024 16:42:39 GMT, Georgi Guninski wrote: >This is based on numerical experiments in sage. > >Let $K$ be a ring and define the ideal where each polynomial >is of the form $(a_i x_i+b_i)(a_j x_j+b_j)=0$ for constant $a_i,b_i,a_j,b_j$. Do you have exactly one (or at most) relation

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

IMHO opaque C objects may be accessed from Python, it just needs an implementation On 29 January 2024 22:51:48 GMT, Nils Bruin wrote: >By the looks of it, the routines you'd be using would be coming from >umfpack. cvxopt has chosen to package the details of LU factorization in >opaque objects

Re: [sage-devel] Failing to build sage for Apple M2 from source because of package cvxopt-1.3.2

Hi, this issue is tracked in https://github.com/sagemath/sage/issues/37149 A solution is proposed in https://github.com/sagemath/sage/pull/37161 HTH Dima On Tue, Jan 30, 2024 at 8:25 AM Wang Steven wrote: > > I build sage following the instructions: > [https://github.com/dealii/dealii/wiki/Apple

Re: [sage-devel] rebuilding Cython files in `conda` installation

On 24 January 2024 15:58:56 GMT, Gareth Ma wrote: >Hi all, my development Sage installation uses the conda instructions here >. > >There is a command below for how to recompi

Re: [sage-devel] Bug in integration on a Riemann surface

On Mon, Jan 22, 2024 at 11:03 AM Linden Disney wrote: > > In Sage 9.8 I ran the following code: > > R. = QQ[] > f = x*(1^5+z^5) + (x*1*z)^2 - x^4*1*z - 2*1^3*z^3 > S = Curve(f).riemann_surface() > S.riemann_matrix() > > and got a ValueError occurring inside rigorous_line_integral.

Re: [sage-devel] Re: Implementing minimum_generating_set() function

(I also want G/N to be >an object of the same class as G.) It's G.quotient(N), no? > >My another question is: How can I find the group operation of a group G? >On Thursday, January 18, 2024 at 7:13:50 PM UTC+5:30 Dima Pasechnik wrote: > >> On Thu, Jan 18, 2024

Re: [sage-devel] SuiteSparse and sage and sparse_matrix.LU()

On Fri, Jan 19, 2024 at 9:35 AM 'Animesh Shree' via sage-devel wrote: > > I have been looking into sparse matrix LU decomposition issue. > > In that conversation SuiteSparse is proposed to handle sparse matrix > decomposition. > > What I could find that it is mostly C and Matlab. I don't know whe

<    1   2   3   4   5   6   7   8   9   10   >