date:20240228

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, could not have been
>> detected by the CI framework.  It is a serious regression and definitely a
>> blocker IMHO: are we willing to release a version of SageMath that cannot
>> be used without an internet connection?
>>
>
> Related to this, do you think
>
> https://github.com/sagemath/sage/issues/34233
>
> should also be a blocker?  In Sage if you create a plot with a large
> y-axis range, the labels on the y axis are
> mathematically incorrect, which is confusing to our largest group of users
> (beginners).
>

Sure, it can be a blocker, very well (or not to overload this word, it
could be "grave" or something).


To plot it, correctly, with sympy, you need to install 3 PyPI packages into
your Python3:
matplotlib, jupyterlab, sympy.

On the other hand, check all the 400 neatly arranged Sage's spkgs, CI
passing with flying colours..
.


>
> -- William
>
>
>>
>> Eric.
>>
>> Le mercredi 28 février 2024 à 07:45:03 UTC+1, Kwankyu Lee a écrit :
>>
>>> 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 delay
>>> the release.
>>> 2. Instead use "critical" label for a very serious and urgent Issue.
>>> 3. A PR fixing the "critical" Issue will likely get the "blocker" label.
>>> 4. Old Issues converted from trac with "critical" label will get the
>>> "major" label instead.
>>>
>>> Voting will end when there is no new vote for a week.
>>>
>>> This is a simple majority voting (following the standard on sage-devel
>>> proposal)!
>>>
>>> A positive vote is for all parts of the Proposal. So if you do not like
>>> any of (1) -- (4), cast a negative vote (-1).
>>>
>>>
>>> Happy voting!
>>>
>> --
>> 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/a2c85e9b-ac46-49d7-8385-f568fddfa236n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> 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/CACLE5GB7pxdZQJO7CV8YvNw3gvrVzcpv-fYXZk0YejkcXdXoxQ%40mail.gmail.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/CAAWYfq2uZEFfiM-cLKoFjxfkTkWhEd5S9B%3DjgZf3qxzcewR5HA%40mail.gmail.com.

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

2024-02-28 Thread Emmanuel Charpentier

Le mercredi 28 février 2024 à 17:39:25 UTC+1, Eric Gourgoulhon a écrit :

-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, could not have been
detected by the CI framework. It is a serious regression and definitely a
blocker IMHO: are we willing to release a version of SageMath that cannot
be used without an internet connection?

Seconded. -1 from me.

A PR fixing a blocker issue sould be an "unblocker". (Some low minds may
think of this as what Molière would have calld "un clystère"...).

OK, I'll show myself out. Sorry...

Eric.

Le mercredi 28 février 2024 à 07:45:03 UTC+1, Kwankyu Lee a écrit :

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 delay the
release.
2. Instead use "critical" label for a very serious and urgent Issue.
3. A PR fixing the "critical" Issue will likely get the "blocker" label.
4. Old Issues converted from trac with "critical" label will get the
"major" label instead.

Voting will end when there is no new vote for a week.

This is a simple majority voting (following the standard on sage-devel
proposal)!

A positive vote is for all parts of the Proposal. So if you do not like any
of (1) -- (4), cast a negative vote (-1).

Happy voting!

--
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/868f9264-0d8f-4666-9786-6a535a040bffn%40googlegroups.com.

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

On Wed, Feb 28, 2024 at 5:42 PM 'Animesh Shree' via sage-devel <
sage-devel@googlegroups.com> wrote:

> reason scipy factors only square sparse matrices
>
> Problem is basically in _superlu.gstrf
> it
> accepts only one dimension as input rather than both row and col.
> In c implementation
> 
> we can see it uses N only
> 
> and assumes A to be square matrix.
>

We can probably change scipy's code (and then do a PR) to accept a
non-square matrix.
The C code they have basically sets up a call to superlu, and gets the
results...


>
> Currently I am going with the solution given by *Dima* which uses block
> matrices.
>
> On Wednesday, February 28, 2024 at 9:49:07 PM UTC+5:30 Animesh Shree wrote:
>
>> Yes
>> Because of same reason I tried to commented scipy code
>> 
>> to test this.
>>
>> I got some error saying *RuntimeError: Factor is exactly singular*
>> But same worked for sage LU factorization in dense matrix for same matrix.
>>
>> -Scipy (Modified)--
>> >>> from scipy.sparse import csc_matrix
>> >>> from scipy.sparse.linalg import splu
>> >>> import numpy as np
>> >>> A = csc_matrix([[1,0,0],[5,0,2]], dtype=np.float64)
>> >>> print(A)
>>   (0, 0) 1.0
>>   (1, 0) 5.0
>>   (1, 2) 2.0
>> >>> splu(A)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File
>> "/home/shay/miniconda3/envs/py39/lib/python3.9/site-packages/scipy/sparse/linalg/_dsolve/linsolve.py",
>> line 440, in splu
>> return _superlu.gstrf(N, A.nnz, A.data, indices, indptr,
>> RuntimeError: Factor is exactly singular
>> >>>
>>
>>
>>
>>
>> -Sage---
>> sage: A = Matrix(RDF, 2,3, [[1,0,0],[5,0,2]])
>> sage: A
>> [1.0 0.0 0.0]
>> [5.0 0.0 2.0]
>> sage: A.LU()
>> (
>> [0.0 1.0]  [1.0 0.0]  [ 5.0  0.0  2.0]
>> [1.0 0.0], [0.2 1.0], [ 0.0  0.0 -0.4]
>> )
>>
>>
>>
>> I am looking into it too.
>>
>>
>> On Wednesday, February 28, 2024 at 8:59:36 PM UTC+5:30 Dima Pasechnik
>> wrote:
>>
>>> There is a good reason for numerics people to adopt "SuperLU"
>>> factorisations over
>>> the classical PLU sparse decomposition - namely, it's more stable.
>>> Perhaps it should be made the Sage's default for sparse RDF matrices,
>>> too.
>>> By the way,
>>> https://portal.nersc.gov/project/sparse/superlu/superlu_ug.pdf
>>> (the manual for the upstream superlu) says it can handle non-square
>>> matrices.
>>>
>>> Dima
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 28, 2024 at 1:09 PM 'Animesh Shree' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
 I went through the link.
 It also returns perm_c and perm_r and the solution is represented as

 Pr * (R^-1) * A * Pc = L * U

 It is similar to one returned by scipy
 >>> lu.perm_r

array([0, 2, 1, 3], dtype=int32)

 >>> lu.perm_c

array([2, 0, 1, 3], dtype=int32)

 I think it doesn't support square matrix too. Link
 
 On Wednesday, February 28, 2024 at 6:17:26 PM UTC+5:30 Max Alekseyev
 wrote:

> One more option would be umfack via scikits.umfpack:
>
> https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html
>
> Regards,
> Max
> On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree
> wrote:
>
>> One thing I would like to suggest.
>>
>> We can provide multiple ways to compute the sparse LU
>> 1. scipy
>> 2. sage original implementation in src.sage.matrix.matrix2.LU
>> 
>>  (Note
>> - link
>> 
>> )
>> 3. convert to dense then factor
>>
>> It will be up to user to choose based on the complexity.
>> Is it fine?
>>
>> On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree
>> wrote:
>>
>>> Thank you for reminding
>>> I went through.
>>> We need to Decompose  A11 only and rest can be calculated via taking
>>> inverse of L11 or U11.
>>> Here A11 is square matrix and we can use scipy to decompose square
>>> matrices.
>>> Am I correct?
>>>
>>> New and only problem that I see is the returned LU decomposition of
>>>

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, but for the LaurentPolynomialRing it just
> seems wrong?
>
>
> I think it's more than just a CS workaround. It has its roots in dimension
> considerations: the space of polynomials of degree at most d is
> (d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect
> sense.
>

well, it's the convention used in Singular.
But GAP and Macaulay2 use -infinity.

The arguments for -infinity:

1) degree of the product should be the sum of degrees; so it's got to be
infinite.
2) it should be -infinity, to make sense of the rule that if you do
division f/g with remainder r,
the degree of the remainder should be less than the deg(r)<=deg(f), but if
r=0 then the only way
to get this is to use -infinity.

Dima


>
> For deg = - ord_infty it should definitely be -oo, though, and for Laurent
> polynomials the dimension argument doesn't work.
>
> --
> 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/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%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/CAAWYfq0tSp1v%3D2t7m70hKkBF%3DtmWY4x54_vSWAza2hcxHJc4CQ%40mail.gmail.com.

[sage-devel] Re: Build test on a PR is giving an error while code is wroking on my machine

2024-02-28 Thread Ricardo Buring

On Wednesday, February 28, 2024 at 7:23:45 PM UTC+1 Ruchit Jagodara wrote:

I recently made a PR regarding the implementation of the 
minimum_generating_set function in polynomial time,#37481 
. However, in this PR, one of 
my build tests is failing and giving a error. I'm bit confused about how to 
solve this because I have never seen this kind of error before. Can 
somebody help me with this?


To start, I would replace "sage: sage: G = ..." by just "sage: G = ..." in 
that example. 

-- 
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/d3a02272-61c3-4516-87c0-f621e4cbff58n%40googlegroups.com.

[sage-devel] Build test on a PR is giving an error while code is wroking on my machine

2024-02-28 Thread 'Ruchit Jagodara' via sage-devel

Hey there! 

I recently made a PR regarding the implementation of the 
minimum_generating_set function in polynomial time,#37481 
. However, in this PR, one of 
my build tests is failing and giving a error. I'm bit confused about how to 
solve this because I have never seen this kind of error before. Can 
somebody help me with this?

** 
18 
File
 
"src/sage/groups/group.pyx", line 275, in 
sage.groups.group.Group.minimum_generating_set 
19 
Failed
 
example: 
20 

 
sage: G = PermutationGroup([(1,2,3), (2,3), (4,5)]) 
21 
Exception
 
raised: 
22 

 
Traceback (most recent call last): 
23 

 
File "/sage/src/sage/doctest/forker.py", line 712, in _run 
24 

 
self.compile_and_execute(example, compiler, test.globs) 
25 

 
File "/sage/src/sage/doctest/forker.py", line 1147, in compile_and_execute 
26 

 
exec(compiled, globs) 
27 

 
File "", line 1, 
in  
28 

 
sage: G = PermutationGroup([(Integer(1),Integer(2),Integer(3)), 
(Integer(2),Integer(3)), (Integer(4),Integer(5))]) 
29 

 
^ 
30 

 
NameError: name 'G' is not defined 
31 

**

-- 
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/3dc24ee3-0424-4c38-9c0e-6b6c24eaaef9n%40googlegroups.com.

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

reason scipy factors only square sparse matrices

Problem is basically in _superlu.gstrf 
it
 
accepts only one dimension as input rather than both row and col.
In c implementation 

 
we can see it uses N only 

 
and assumes A to be square matrix.

Currently I am going with the solution given by *Dima* which uses block 
matrices.

On Wednesday, February 28, 2024 at 9:49:07 PM UTC+5:30 Animesh Shree wrote:

> Yes 
> Because of same reason I tried to commented scipy code 
> 
>  
> to test this.
>
> I got some error saying *RuntimeError: Factor is exactly singular*
> But same worked for sage LU factorization in dense matrix for same matrix.
>
> -Scipy (Modified)--
> >>> from scipy.sparse import csc_matrix
> >>> from scipy.sparse.linalg import splu
> >>> import numpy as np
> >>> A = csc_matrix([[1,0,0],[5,0,2]], dtype=np.float64)
> >>> print(A)
>   (0, 0) 1.0
>   (1, 0) 5.0
>   (1, 2) 2.0
> >>> splu(A)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/home/shay/miniconda3/envs/py39/lib/python3.9/site-packages/scipy/sparse/linalg/_dsolve/linsolve.py",
>  
> line 440, in splu
> return _superlu.gstrf(N, A.nnz, A.data, indices, indptr,
> RuntimeError: Factor is exactly singular
> >>> 
>
>
>
>
> -Sage---
> sage: A = Matrix(RDF, 2,3, [[1,0,0],[5,0,2]])
> sage: A
> [1.0 0.0 0.0]
> [5.0 0.0 2.0]
> sage: A.LU()
> (
> [0.0 1.0]  [1.0 0.0]  [ 5.0  0.0  2.0]
> [1.0 0.0], [0.2 1.0], [ 0.0  0.0 -0.4]
> )
>
>
>
> I am looking into it too. 
>
>
> On Wednesday, February 28, 2024 at 8:59:36 PM UTC+5:30 Dima Pasechnik 
> wrote:
>
>> There is a good reason for numerics people to adopt "SuperLU" 
>> factorisations over
>> the classical PLU sparse decomposition - namely, it's more stable.
>> Perhaps it should be made the Sage's default for sparse RDF matrices, too.
>> By the way, 
>> https://portal.nersc.gov/project/sparse/superlu/superlu_ug.pdf
>> (the manual for the upstream superlu) says it can handle non-square 
>> matrices.
>>
>> Dima
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 28, 2024 at 1:09 PM 'Animesh Shree' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> I went through the link.
>>> It also returns perm_c and perm_r and the solution is represented as
>>>
>>> Pr * (R^-1) * A * Pc = L * U
>>>
>>> It is similar to one returned by scipy
>>> >>> lu.perm_r
>>>
>>>array([0, 2, 1, 3], dtype=int32)
>>>
>>> >>> lu.perm_c
>>>
>>>array([2, 0, 1, 3], dtype=int32)
>>>
>>> I think it doesn't support square matrix too. Link 
>>> 
>>> On Wednesday, February 28, 2024 at 6:17:26 PM UTC+5:30 Max Alekseyev 
>>> wrote:
>>>
 One more option would be umfack via scikits.umfpack:

 https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html

 Regards,
 Max
 On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree wrote:

> One thing I would like to suggest.
>
> We can provide multiple ways to compute the sparse LU
> 1. scipy 
> 2. sage original implementation in src.sage.matrix.matrix2.LU 
> 
>  (Note 
> - link 
> 
> )
> 3. convert to dense then factor
>
> It will be up to user to choose based on the complexity.
> Is it fine?
>
> On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree 
> wrote:
>
>> Thank you for reminding
>> I went through. 
>> We need to Decompose  A11 only and rest can be calculated via taking 
>> inverse of L11 or U11.
>> Here A11 is square matrix and we can use scipy to decompose square 
>> matrices.
>> Am I correct?
>>
>> New and only problem that I see is the returned LU decomposition of 
>> scipy's splu is calculated by full permutation of row and column as 
>> pointed 
>> out by *Nils Bruin*. We will be returning row and col permutation 
>> array/matrix separately 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

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

2024-02-28 Thread Nils Bruin

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, but for the LaurentPolynomialRing it just 
seems wrong?


I think it's more than just a CS workaround. It has its roots in dimension 
considerations: the space of polynomials of degree at most d is 
(d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect 
sense.

For deg = - ord_infty it should definitely be -oo, though, and for Laurent 
polynomials the dimension argument doesn't work.

-- 
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/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com.

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

2024-02-28 Thread William Stein

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, could not have been
> detected by the CI framework.  It is a serious regression and definitely a
> blocker IMHO: are we willing to release a version of SageMath that cannot
> be used without an internet connection?
>

Related to this, do you think

https://github.com/sagemath/sage/issues/34233

should also be a blocker?  In Sage if you create a plot with a large y-axis
range, the labels on the y axis are
mathematically incorrect, which is confusing to our largest group of users
(beginners).

-- William


>
> Eric.
>
> Le mercredi 28 février 2024 à 07:45:03 UTC+1, Kwankyu Lee a écrit :
>
>> 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 delay the
>> release.
>> 2. Instead use "critical" label for a very serious and urgent Issue.
>> 3. A PR fixing the "critical" Issue will likely get the "blocker" label.
>> 4. Old Issues converted from trac with "critical" label will get the
>> "major" label instead.
>>
>> Voting will end when there is no new vote for a week.
>>
>> This is a simple majority voting (following the standard on sage-devel
>> proposal)!
>>
>> A positive vote is for all parts of the Proposal. So if you do not like
>> any of (1) -- (4), cast a negative vote (-1).
>>
>>
>> Happy voting!
>>
> --
> 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/a2c85e9b-ac46-49d7-8385-f568fddfa236n%40googlegroups.com
> 
> .
>


-- 
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/CACLE5GB7pxdZQJO7CV8YvNw3gvrVzcpv-fYXZk0YejkcXdXoxQ%40mail.gmail.com.

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

I am currently working for RDF and CDF mainly. I was planning to overload 
LU function of *sage/matrix/matrix2.pyx*  by defining new LU in 
*sage/matrix/matrix_double_sparce.pyx* .

I couldn't understand what is  multiprecision version but I guess you are 
asking for RR or other inexact field.
Please correct me if I am wrong.

On Wednesday, February 28, 2024 at 9:51:32 PM UTC+5:30 Nils Bruin wrote:

> As Dima points out, SPLU decomposition is probably more useful in 
> practice, so it's great to expose it. It should probably be exposed through 
> a different method than PLU decomposition, though.
>
> For the return format: permutations are much more compact and efficient to 
> describe permutations than permutation matrices. Also because of the 
> parent: a permutation matrix is a {0,1}-valued matrix so it can be well 
> represented over ZZ, rather than floats. So primarily the routine should 
> expose that scipy exposes. Whether other bells and whistles are required is 
> another matter.
>
> Is this only for system floats/complex numbers? or will you also be 
> implementing multiprecision versions? 
>

-- 
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/32c0253b-6456-4522-8638-8dd958687bf6n%40googlegroups.com.

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

2024-02-28 Thread Eric Gourgoulhon

-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, could not have been 
detected by the CI framework.  It is a serious regression and definitely a 
blocker IMHO: are we willing to release a version of SageMath that cannot 
be used without an internet connection?

Eric.

Le mercredi 28 février 2024 à 07:45:03 UTC+1, Kwankyu Lee a écrit :

> 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 delay the 
> release.
> 2. Instead use "critical" label for a very serious and urgent Issue.
> 3. A PR fixing the "critical" Issue will likely get the "blocker" label.
> 4. Old Issues converted from trac with "critical" label will get the 
> "major" label instead. 
>
> Voting will end when there is no new vote for a week.
>
> This is a simple majority voting (following the standard on sage-devel 
> proposal)!
>
> A positive vote is for all parts of the Proposal. So if you do not like 
> any of (1) -- (4), cast a negative vote (-1).
>
>
> Happy voting! 
>

-- 
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/a2c85e9b-ac46-49d7-8385-f568fddfa236n%40googlegroups.com.

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

2024-02-28 Thread Nils Bruin

As Dima points out, SPLU decomposition is probably more useful in practice, 
so it's great to expose it. It should probably be exposed through a 
different method than PLU decomposition, though.

For the return format: permutations are much more compact and efficient to 
describe permutations than permutation matrices. Also because of the 
parent: a permutation matrix is a {0,1}-valued matrix so it can be well 
represented over ZZ, rather than floats. So primarily the routine should 
expose that scipy exposes. Whether other bells and whistles are required is 
another matter.

Is this only for system floats/complex numbers? or will you also be 
implementing multiprecision versions? 

-- 
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/f680547f-33dc-4c43-be78-6f54ed11e798n%40googlegroups.com.

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

Yes 
Because of same reason I tried to commented scipy code 

 
to test this.

I got some error saying *RuntimeError: Factor is exactly singular*
But same worked for sage LU factorization in dense matrix for same matrix.

-Scipy (Modified)--
>>> from scipy.sparse import csc_matrix
>>> from scipy.sparse.linalg import splu
>>> import numpy as np
>>> A = csc_matrix([[1,0,0],[5,0,2]], dtype=np.float64)
>>> print(A)
  (0, 0) 1.0
  (1, 0) 5.0
  (1, 2) 2.0
>>> splu(A)
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/shay/miniconda3/envs/py39/lib/python3.9/site-packages/scipy/sparse/linalg/_dsolve/linsolve.py",
 
line 440, in splu
return _superlu.gstrf(N, A.nnz, A.data, indices, indptr,
RuntimeError: Factor is exactly singular
>>> 




-Sage---
sage: A = Matrix(RDF, 2,3, [[1,0,0],[5,0,2]])
sage: A
[1.0 0.0 0.0]
[5.0 0.0 2.0]
sage: A.LU()
(
[0.0 1.0]  [1.0 0.0]  [ 5.0  0.0  2.0]
[1.0 0.0], [0.2 1.0], [ 0.0  0.0 -0.4]
)



I am looking into it too. 


On Wednesday, February 28, 2024 at 8:59:36 PM UTC+5:30 Dima Pasechnik wrote:

> There is a good reason for numerics people to adopt "SuperLU" 
> factorisations over
> the classical PLU sparse decomposition - namely, it's more stable.
> Perhaps it should be made the Sage's default for sparse RDF matrices, too.
> By the way, https://portal.nersc.gov/project/sparse/superlu/superlu_ug.pdf
> (the manual for the upstream superlu) says it can handle non-square 
> matrices.
>
> Dima
>
>
>
>
>
>
>
>
> On Wed, Feb 28, 2024 at 1:09 PM 'Animesh Shree' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> I went through the link.
>> It also returns perm_c and perm_r and the solution is represented as
>>
>> Pr * (R^-1) * A * Pc = L * U
>>
>> It is similar to one returned by scipy
>> >>> lu.perm_r
>>
>>array([0, 2, 1, 3], dtype=int32)
>>
>> >>> lu.perm_c
>>
>>array([2, 0, 1, 3], dtype=int32)
>>
>> I think it doesn't support square matrix too. Link 
>> 
>> On Wednesday, February 28, 2024 at 6:17:26 PM UTC+5:30 Max Alekseyev 
>> wrote:
>>
>>> One more option would be umfack via scikits.umfpack:
>>>
>>> https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html
>>>
>>> Regards,
>>> Max
>>> On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree wrote:
>>>
 One thing I would like to suggest.

 We can provide multiple ways to compute the sparse LU
 1. scipy 
 2. sage original implementation in src.sage.matrix.matrix2.LU 
 
  (Note 
 - link 
 
 )
 3. convert to dense then factor

 It will be up to user to choose based on the complexity.
 Is it fine?

 On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree 
 wrote:

> Thank you for reminding
> I went through. 
> We need to Decompose  A11 only and rest can be calculated via taking 
> inverse of L11 or U11.
> Here A11 is square matrix and we can use scipy to decompose square 
> matrices.
> Am I correct?
>
> New and only problem that I see is the returned LU decomposition of 
> scipy's splu is calculated by full permutation of row and column as 
> pointed 
> out by *Nils Bruin*. We will be returning row and col permutation 
> array/matrix separately 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 & p={perm_r, perm_c}
> or
> We can leave that to user
> User will have to permute its input data according to perm_c (like : 
> perm_c * input) before using the perm_r^(-1) * L * U
> as perm_r^(-1) * L * U is PLU decomposition of Original_matrix*perm_c
>
> https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html
> >>> A = Pr^(-1) *L*U * Pc^(-1) # as told by *Nils Bruin*
> or
> scipy's splu will not do.
>
> On Tuesday, February 27, 2024 at 11:57:02 PM UTC+5:30 Dima Pasechnik 
> wrote:
>
>>
>>
>> On 27 February 2024 17:25:51 GMT, 'Animesh Shree' via sage-devel <
>> sage-...@googlegroups.com> wrote: 
>> >This works good if input is square and I also checked on your idea 
>> of 
>> >padding zeros for non square matrices. 
>> >I am currently concerned about the permutation matrix and L, U in 
>>

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

Not a "maths" why, but I know anything which uses singular currently 
returns -1 because of the following snippet

cdef long singular_polynomial_deg(poly *p, poly *x, ring *r) noexcept:
cdef long _deg, deg
cdef int dummy

deg = -1
_deg = -1
if p == NULL:
return -1
...

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, but for the LaurentPolynomialRing it just 
seems wrong?
On Wednesday, February 28, 2024 at 3:29:25 PM UTC Dima Pasechnik wrote:

> 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-...@googlegroups.com> wrote:
>
>> 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. = LazyLaurentSeriesRing(QQ)
>>> sage: R.zero().degree()
>>>
>>> ---
>>> AttributeErrorTraceback (most recent call 
>>> last)
>>> Cell In[4], line 1
>>> > 1 R.zero().degree()
>>>
>>> File ~/sage/sage/src/sage/structure/element.pyx:489, in 
>>> sage.structure.element.Element.__getattr__()
>>> 487 AttributeError: 
>>> 'LeftZeroSemigroup_with_category.element_class' object has no attribute 
>>> 'blah_blah'...
>>> 488 """
>>> --> 489 return self.getattr_from_category(name)
>>> 490 
>>> 491 cdef getattr_from_category(self, name) noexcept:
>>>
>>> File ~/sage/sage/src/sage/structure/element.pyx:502, in 
>>> sage.structure.element.Element.getattr_from_category()
>>> 500 else:
>>> 501 cls = P._abstract_element_class
>>> --> 502 return getattr_from_other_class(self, cls, name)
>>> 503 
>>> 504 def __dir__(self):
>>>
>>> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
>>> sage.cpython.getattr.getattr_from_other_class()
>>> 355 dummy_error_message.cls = type(self)
>>> 356 dummy_error_message.name = name
>>> --> 357 raise AttributeError(dummy_error_message)
>>> 358 cdef PyObject* attr = instance_getattr(cls, name)
>>> 359 if attr is NULL:
>>>
>>> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' 
>>> object has no attribute 'degree'
>>>
>>> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>>>
 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 writing randomised testing I got myself confused about the degree 
> of the zero polynomial. For the univariate and multivariate polynomial 
> rings, we currently use that the degree for 0 (both R(0).degree() as well 
> as R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>
> However for the LaurentPolynomialRings, a polynomial with negative 
> valuation is very natural. For example the following code snippet shows 
> the 
> ambiguity.
>
> sage: L. = LaurentPolynomialRing(QQ)
> sage: f = (1/x); f
> x^-1
> sage: f.degree()
> -1
> sage: L.zero().degree()
> -1
>
> I don't feel familiar enough with the mathematics here and the usual 
> use cases in sage to offer a PR "fixing" this, or whether it even needs 
> fixing. However, I got confused so I thought maybe others might get 
> confused and someone on this list might have a suggestion.
>
> I think the "usual" suggestion would be to have the degree as -infty, 
> but then there's a question about whether this should be done for other 
> polynomial rings...
>
> I made an issue for this on GitHub too:
>
> https://github.com/sagemath/sage/issues/37491
>
 -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/c9c805f9-fbd0-4591-8729-002f3ad90fa1n%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

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 uncovered
> (usually) trivial bugs. I then write new PRs to fix these bugs.
>
> If there is code causing CI failure in random testing, should I mark the
> fix for this as a "blocker", even if the chance of this failure is small? I
> don't want to be melodramatic in my PR for fixes but I also want to make
> sure I'm labelling things as expected,
>

I don't think we ever tag anything but most onerous maths bugs as blockers
(e.g. we have a plenty of outstanding symbolic integration bugs).
That is, unless it's absolutely Earth-shuttering, don't use "blocker".

Dima


>
> On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:
>
>> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>>
>>> Thank you for making progress on these urgent issues. I suggest the
>>> following:
>>>
>>> 1. Open two other new threads, each of which is for voting on each
>>> proposal.
>>> 2. On a proposal, it should be clear that *a positive vote (+1) is for
>>> the whole proposal,* and if one is negative to any part of the
>>> proposal, (s)he should give a negative vote (-1).
>>>
>>
>> Voting threads seem reasonable.  I'll wait a day or two to see if people
>> have any final comments before voting.
>>
>>
>>> 3. A proposal is accepted if the number of positive votes is at least
>>> twice of the number of the negative votes.
>>>
>>
>> Despite the fact that we're asking for this threshold in voting on a PR,
>> the standard for votes on proposals on sage-devel is just a plain majority
>> (though of course I hope that we can come to a 2-1 consensus!).
>>
>> A minor suggestion for Proposal 2: for the label to be readable, I
>>> suggest "CI fix" for the name of the label (a blank between words).
>>>
>>
>> I'm happy to adjust the label to be "CI fix."
>>
>>
>>> We may use this thread to get more comments on the Proposals before
>>> opening voting threads.
>>>
>>> --
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/554961a0-4ace-4317-bfcf-55b6a128bcden%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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%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/CAAWYfq2eMM%3DzUHCZ_dpfDvxattotQmaD-0kht6J8ZxCL9K005w%40mail.gmail.com.

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 delay the
> release.
> 2. Instead use "critical" label for a very serious and urgent Issue.
>

Still, how about one level up from "critical" for issues? (need not be
called "blocker", might be something like "grave" ?

Dima


> 3. A PR fixing the "critical" Issue will likely get the "blocker" label.
> 4. Old Issues converted from trac with "critical" label will get the
> "major" label instead.
>
> Voting will end when there is no new vote for a week.
>
> This is a simple majority voting (following the standard on sage-devel
> proposal)!
>
> A positive vote is for all parts of the Proposal. So if you do not like
> any of (1) -- (4), cast a negative vote (-1).
>
>
> Happy voting!
>
> --
> 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/0f9b1d58-a50e-437b-a914-f0a31731626cn%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/CAAWYfq0rXB7BmDpTEhA8XXz_%3DOyxw-BsCrV%2BOQUwzSERMt6qBw%40mail.gmail.com.

Re: [sage-devel] Looking for volunteers

2024-02-28 Thread David Roe

On Wed, Feb 28, 2024 at 10:51 AM Dima Pasechnik  wrote:

>
>> We propose the following voting system.
>> 1. A nomination period of 1 week, where any Sage developer can nominate
>> someone to serve on the committee by emailing sage-ab...@googlegroups.com.
>> You are allowed to nominate yourself (and we encourage it); if you nominate
>> someone else we will email them and ask if they are willing to serve.  To
>> be eligible you should have
>> a. Contributed code to Sage at some point in the past
>> b. Not been subject to a complaint to the committee at any point.
>>
>
> b. sounds way too broad to me. Should it say in addition something like
> "The complaint in question only qualifies if it was ruled valid by the
> committee." Note that these complaints were misused in the past.
>

Sure, that seems reasonable.
David

-- 
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/CAChs6_nJ-TfF2E1LOkf5YiJVfTC1F_60H7tbS5i0W5D1sOhSkg%40mail.gmail.com.

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
> violations is a committee, reachable at sage-ab...@googlegroups.com.  I
> announced the membership of this committee a few days ago in another
> thread; since then one member has resigned and another has expressed
> willingness to be replaced.  The current membership is
> William Stein
> John Palmieri
> David Roe
> Vincent Delecroix
> David Joyner
> As a group, we believe that this committee would benefit from new members,
> so we are opening a process to add and/or change the membership (the five
> of us will go through the same process described below as anyone else
> interested in serving on the committee).
>
> We propose the following voting system.
> 1. A nomination period of 1 week, where any Sage developer can nominate
> someone to serve on the committee by emailing sage-ab...@googlegroups.com.
> You are allowed to nominate yourself (and we encourage it); if you nominate
> someone else we will email them and ask if they are willing to serve.  To
> be eligible you should have
> a. Contributed code to Sage at some point in the past
> b. Not been subject to a complaint to the committee at any point.
>

b. sounds way too broad to me. Should it say in addition something like
"The complaint in question only qualifies if it was ruled valid by the
committee." Note that these complaints were misused in the past.



> During the nomination period, you may also write to sage-abuse with names
> of people who you believe should not serve on the committee; if one of
> these people is nominated we will write to you asking for more
> justification.  If you have a reservation about someone already on the
> committee, you should feel free to write to us individually.
> 2. After the nomination period, we will announce nominees on sage-devel,
> and ask for votes (which will also be sent to sage-ab...@googlegroups.com).
> Voting will be by approval voting (you can select an arbitrary number of
> people to vote for, unordered).  The committee will include at least the
> top 5 candidates, and will be enlarged to include all tied candidates if
> there is a tie for 5th place.
> 3. After a week of voting, we will announce the new composition of the
> committee.
>
> We're aware that this process is not optimal (and welcome suggestions for
> improvement).  But we'd like more help, soon.  So we will open nominations
> in parallel to discussion of the process.  We anticipate running this
> process every 3 years to refresh membership.
>
> Qualities that we're looking for are
> 1. Tactfulness and judgement in moderating conflicts and addressing abuse
> 2. Willingness to put time and effort into repairing some of the problems
> that we've seen in our community.
> If you have any questions, feel free to reach out to us individually, or
> as a group.  We will be following this with some proposed changes to the
> Code of Conduct, as well as a new document describing how we handle reports
> (following the example of SciPy and NumFocus).  Thanks,
> David
> for the sage-abuse committee
>
> --
> 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/CAChs6_kDCa8TYWnQ10pLtpOewSKaCQBFkhb6w3hZ%2BLbQEgsN2A%40mail.gmail.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/CAAWYfq0m%2BX3uT30W2Zxfu%2BuNphKvLLRuM7RQZOL2qDBtXSOLhA%40mail.gmail.com.

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

There is a good reason for numerics people to adopt "SuperLU"
factorisations over
the classical PLU sparse decomposition - namely, it's more stable.
Perhaps it should be made the Sage's default for sparse RDF matrices, too.
By the way, https://portal.nersc.gov/project/sparse/superlu/superlu_ug.pdf
(the manual for the upstream superlu) says it can handle non-square
matrices.

Dima








On Wed, Feb 28, 2024 at 1:09 PM 'Animesh Shree' via sage-devel <
sage-devel@googlegroups.com> wrote:

> I went through the link.
> It also returns perm_c and perm_r and the solution is represented as
>
> Pr * (R^-1) * A * Pc = L * U
>
> It is similar to one returned by scipy
> >>> lu.perm_r
>
>array([0, 2, 1, 3], dtype=int32)
>
> >>> lu.perm_c
>
>array([2, 0, 1, 3], dtype=int32)
>
> I think it doesn't support square matrix too. Link
> 
> On Wednesday, February 28, 2024 at 6:17:26 PM UTC+5:30 Max Alekseyev wrote:
>
>> One more option would be umfack via scikits.umfpack:
>>
>> https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html
>>
>> Regards,
>> Max
>> On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree wrote:
>>
>>> One thing I would like to suggest.
>>>
>>> We can provide multiple ways to compute the sparse LU
>>> 1. scipy
>>> 2. sage original implementation in src.sage.matrix.matrix2.LU
>>> 
>>>  (Note
>>> - link
>>> 
>>> )
>>> 3. convert to dense then factor
>>>
>>> It will be up to user to choose based on the complexity.
>>> Is it fine?
>>>
>>> On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree
>>> wrote:
>>>
 Thank you for reminding
 I went through.
 We need to Decompose  A11 only and rest can be calculated via taking
 inverse of L11 or U11.
 Here A11 is square matrix and we can use scipy to decompose square
 matrices.
 Am I correct?

 New and only problem that I see is the returned LU decomposition of
 scipy's splu is calculated by full permutation of row and column as pointed
 out by *Nils Bruin*. We will be returning row and col permutation
 array/matrix separately 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
 & p={perm_r, perm_c}
 or
 We can leave that to user
 User will have to permute its input data according to perm_c (like :
 perm_c * input) before using the perm_r^(-1) * L * U
 as perm_r^(-1) * L * U is PLU decomposition of Original_matrix*perm_c

 https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html
 >>> A = Pr^(-1) *L*U * Pc^(-1) # as told by *Nils Bruin*
 or
 scipy's splu will not do.

 On Tuesday, February 27, 2024 at 11:57:02 PM UTC+5:30 Dima Pasechnik
 wrote:

>
>
> On 27 February 2024 17:25:51 GMT, 'Animesh Shree' via sage-devel <
> sage-...@googlegroups.com> wrote:
> >This works good if input is square and I also checked on your idea of
> >padding zeros for non square matrices.
> >I am currently concerned about the permutation matrix and L, U in
> case of
> >padded 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:
> >
> >>
> >>
> >> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel <
> >> sage-...@googlegroups.com> wrote:
> >> >I tried scipy which uses superLU. We get the result but there is
> little
> >> bit
> >> >of issue.
> >> >
> >> >
> >> >--For Dense--
> >> >The dense matrix factorization gives this output using permutation
> matrix
> >> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True)
> >> >sage: a
> >> >[1.0 0.0]
> >> >[2.0 1.0]
> >> >sage: p,l,u = a.dense_matrix().LU()
> >> >sage: p
> >> >[0.0 1.0]
> >> >[1.0 0.0]
> >> >sage: l
> >> >[1.0 0.0]
> >> >[0.5 1.0]
> >> >sage: u
> >> >[ 2.0 1.0]
> >> >[ 0.0 -0.5]
> >> >
> >>
> >> you'd probably want to convert the permutation matrix into a
> permutation.
> >>
> >>
> >> >--For Sparse--
> >> >But the scipy LU decomposition uses permutations which involves
> taking
> >>

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 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. = LazyLaurentSeriesRing(QQ)
>> sage: R.zero().degree()
>>
>> ---
>> AttributeErrorTraceback (most recent call
>> last)
>> Cell In[4], line 1
>> > 1 R.zero().degree()
>>
>> File ~/sage/sage/src/sage/structure/element.pyx:489, in
>> sage.structure.element.Element.__getattr__()
>> 487 AttributeError:
>> 'LeftZeroSemigroup_with_category.element_class' object has no attribute
>> 'blah_blah'...
>> 488 """
>> --> 489 return self.getattr_from_category(name)
>> 490
>> 491 cdef getattr_from_category(self, name) noexcept:
>>
>> File ~/sage/sage/src/sage/structure/element.pyx:502, in
>> sage.structure.element.Element.getattr_from_category()
>> 500 else:
>> 501 cls = P._abstract_element_class
>> --> 502 return getattr_from_other_class(self, cls, name)
>> 503
>> 504 def __dir__(self):
>>
>> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in
>> sage.cpython.getattr.getattr_from_other_class()
>> 355 dummy_error_message.cls = type(self)
>> 356 dummy_error_message.name = name
>> --> 357 raise AttributeError(dummy_error_message)
>> 358 cdef PyObject* attr = instance_getattr(cls, name)
>> 359 if attr is NULL:
>>
>> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class'
>> object has no attribute 'degree'
>>
>> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>>
>>> 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 writing randomised testing I got myself confused about the degree
 of the zero polynomial. For the univariate and multivariate polynomial
 rings, we currently use that the degree for 0 (both R(0).degree() as well
 as R(0).degree(x)) is -1. This is unambiguous for the case of these types.

 However for the LaurentPolynomialRings, a polynomial with negative
 valuation is very natural. For example the following code snippet shows the
 ambiguity.

 sage: L. = LaurentPolynomialRing(QQ)
 sage: f = (1/x); f
 x^-1
 sage: f.degree()
 -1
 sage: L.zero().degree()
 -1

 I don't feel familiar enough with the mathematics here and the usual
 use cases in sage to offer a PR "fixing" this, or whether it even needs
 fixing. However, I got confused so I thought maybe others might get
 confused and someone on this list might have a suggestion.

 I think the "usual" suggestion would be to have the degree as -infty,
 but then there's a question about whether this should be done for other
 polynomial rings...

 I made an issue for this on GitHub too:

 https://github.com/sagemath/sage/issues/37491

>>> --
> 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/c9c805f9-fbd0-4591-8729-002f3ad90fa1n%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/CAAWYfq1QT6dkzM7-YtwQERS6PSTEMxGTsWPbRM-6d9w8KgfCXg%40mail.gmail.com.

[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: R.zero().valuation()
> +Infinity
> sage: R.zero().degree()
> -1
> sage: 
> sage: R. = LaurentPolynomialRing(QQ)
> sage: R.zero().valuation()
> +Infinity
> sage: R.zero().degree()
> -1
> sage: 
> sage: R. = LazyLaurentSeriesRing(QQ)
> sage: R.zero().valuation()
> +Infinity
> sage: R.zero().degree()
> # Errors
>
>
>
> On Wednesday, February 28, 2024 at 1:50:23 PM UTC Martin R wrote:
>
>> 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. = LazyLaurentSeriesRing(QQ)
>>> sage: R.zero().degree()
>>>
>>> ---
>>> AttributeErrorTraceback (most recent call 
>>> last)
>>> Cell In[4], line 1
>>> > 1 R.zero().degree()
>>>
>>> File ~/sage/sage/src/sage/structure/element.pyx:489, in 
>>> sage.structure.element.Element.__getattr__()
>>> 487 AttributeError: 
>>> 'LeftZeroSemigroup_with_category.element_class' object has no attribute 
>>> 'blah_blah'...
>>> 488 """
>>> --> 489 return self.getattr_from_category(name)
>>> 490 
>>> 491 cdef getattr_from_category(self, name) noexcept:
>>>
>>> File ~/sage/sage/src/sage/structure/element.pyx:502, in 
>>> sage.structure.element.Element.getattr_from_category()
>>> 500 else:
>>> 501 cls = P._abstract_element_class
>>> --> 502 return getattr_from_other_class(self, cls, name)
>>> 503 
>>> 504 def __dir__(self):
>>>
>>> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
>>> sage.cpython.getattr.getattr_from_other_class()
>>> 355 dummy_error_message.cls = type(self)
>>> 356 dummy_error_message.name = name
>>> --> 357 raise AttributeError(dummy_error_message)
>>> 358 cdef PyObject* attr = instance_getattr(cls, name)
>>> 359 if attr is NULL:
>>>
>>> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' 
>>> object has no attribute 'degree'
>>>
>>> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>>>
 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 writing randomised testing I got myself confused about the degree 
> of the zero polynomial. For the univariate and multivariate polynomial 
> rings, we currently use that the degree for 0 (both R(0).degree() as well 
> as R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>
> However for the LaurentPolynomialRings, a polynomial with negative 
> valuation is very natural. For example the following code snippet shows 
> the 
> ambiguity.
>
> sage: L. = LaurentPolynomialRing(QQ)
> sage: f = (1/x); f
> x^-1
> sage: f.degree()
> -1
> sage: L.zero().degree()
> -1
>
> I don't feel familiar enough with the mathematics here and the usual 
> use cases in sage to offer a PR "fixing" this, or whether it even needs 
> fixing. However, I got confused so I thought maybe others might get 
> confused and someone on this list might have a suggestion.
>
> I think the "usual" suggestion would be to have the degree as -infty, 
> but then there's a question about whether this should be done for other 
> polynomial rings...
>
> I made an issue for this on GitHub too:
>
> https://github.com/sagemath/sage/issues/37491
>


-- 
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/af56b134-6c48-4d4d-aad8-cbfa1adc1d28n%40googlegroups.com.

[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 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 
>> 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]], sparse=True)
>> sage: b = vector(GF(3), [1], sparse=True)
>> sage: m.solve_right(b)
>>
>> ---
>> TypeError Traceback (most recent call 
>> last)
>> Cell In[157], line 1
>> > 1 m.solve_right(b)
>>
>> File ~/sage/src/sage/matrix/matrix2.pyx:942, in 
>> sage.matrix.matrix2.Matrix.solve_right()
>> 940 else:
>> 941 try:
>> --> 942 X = self._solve_right_nonsingular_square(C, 
>> check_rank=True)
>> 943 except NotFullRankError:
>> 944 X = self._solve_right_general(C, check=check)
>>
>> File ~/sage/src/sage/matrix/matrix_modn_sparse.pyx:948, in 
>> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse._solve_right_nonsingular_square()
>> 946 if isinstance(B, Matrix):
>> 947 from sage.matrix.special import diagonal_matrix
>> --> 948 m, d = self._solve_matrix_linbox(B, algorithm)
>> 949 return m  * diagonal_matrix([QQ((1,x)) for x in d])
>> 950 else:
>>
>> File ~/sage/src/sage/matrix/matrix_modn_sparse.pyx:1132, in 
>> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse._solve_matrix_linbox()
>>1130 
>>1131 cdef givaro.ZRing givZZ
>> -> 1132 cdef linbox.SparseMatrix_integer * A = 
>> new_linbox_matrix_integer_sparse(givZZ, self)
>>1133 cdef linbox.DenseVector_integer * b = new 
>> linbox.DenseVector_integer(givZZ,  self._nrows)
>>1134 cdef linbox.DenseVector_integer * res = new 
>> linbox.DenseVector_integer(givZZ,  self._ncols)
>>
>> TypeError: Cannot convert 
>> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse to 
>> sage.matrix.matrix_integer_sparse.Matrix_integer_sparse
>>
>>

-- 
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/f91ad637-62cb-4ca2-b988-239da25d55dbn%40googlegroups.com.

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

2024-02-28 Thread Kwankyu Lee



If there is code causing CI failure in random testing, should I mark the 
fix for this as a "blocker", even if the chance of this failure is small?


No. A "blocker" blocks the release. We use it for serious fixes worth the 
delay. 

-- 
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/dfc5bbd0-eecb-45f4-a8f0-487933c5300en%40googlegroups.com.

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

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: R.zero().valuation()
+Infinity
sage: R.zero().degree()
-1
sage: 
sage: R. = LaurentPolynomialRing(QQ)
sage: R.zero().valuation()
+Infinity
sage: R.zero().degree()
-1
sage: 
sage: R. = LazyLaurentSeriesRing(QQ)
sage: R.zero().valuation()
+Infinity
sage: R.zero().degree()
# Errors



On Wednesday, February 28, 2024 at 1:50:23 PM UTC Martin R wrote:

> 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. = LazyLaurentSeriesRing(QQ)
>> sage: R.zero().degree()
>>
>> ---
>> AttributeErrorTraceback (most recent call 
>> last)
>> Cell In[4], line 1
>> > 1 R.zero().degree()
>>
>> File ~/sage/sage/src/sage/structure/element.pyx:489, in 
>> sage.structure.element.Element.__getattr__()
>> 487 AttributeError: 
>> 'LeftZeroSemigroup_with_category.element_class' object has no attribute 
>> 'blah_blah'...
>> 488 """
>> --> 489 return self.getattr_from_category(name)
>> 490 
>> 491 cdef getattr_from_category(self, name) noexcept:
>>
>> File ~/sage/sage/src/sage/structure/element.pyx:502, in 
>> sage.structure.element.Element.getattr_from_category()
>> 500 else:
>> 501 cls = P._abstract_element_class
>> --> 502 return getattr_from_other_class(self, cls, name)
>> 503 
>> 504 def __dir__(self):
>>
>> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
>> sage.cpython.getattr.getattr_from_other_class()
>> 355 dummy_error_message.cls = type(self)
>> 356 dummy_error_message.name = name
>> --> 357 raise AttributeError(dummy_error_message)
>> 358 cdef PyObject* attr = instance_getattr(cls, name)
>> 359 if attr is NULL:
>>
>> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' 
>> object has no attribute 'degree'
>>
>> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>>
>>> 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 writing randomised testing I got myself confused about the degree 
 of the zero polynomial. For the univariate and multivariate polynomial 
 rings, we currently use that the degree for 0 (both R(0).degree() as well 
 as R(0).degree(x)) is -1. This is unambiguous for the case of these types.

 However for the LaurentPolynomialRings, a polynomial with negative 
 valuation is very natural. For example the following code snippet shows 
 the 
 ambiguity.

 sage: L. = LaurentPolynomialRing(QQ)
 sage: f = (1/x); f
 x^-1
 sage: f.degree()
 -1
 sage: L.zero().degree()
 -1

 I don't feel familiar enough with the mathematics here and the usual 
 use cases in sage to offer a PR "fixing" this, or whether it even needs 
 fixing. However, I got confused so I thought maybe others might get 
 confused and someone on this list might have a suggestion.

 I think the "usual" suggestion would be to have the degree as -infty, 
 but then there's a question about whether this should be done for other 
 polynomial rings...

 I made an issue for this on GitHub too:

 https://github.com/sagemath/sage/issues/37491

>>>

-- 
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/1d06c246-f250-4c37-997e-066ddaefbaean%40googlegroups.com.

[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. = LazyLaurentSeriesRing(QQ)
> sage: R.zero().degree()
> ---
> AttributeErrorTraceback (most recent call last)
> Cell In[4], line 1
> > 1 R.zero().degree()
>
> File ~/sage/sage/src/sage/structure/element.pyx:489, in 
> sage.structure.element.Element.__getattr__()
> 487 AttributeError: 
> 'LeftZeroSemigroup_with_category.element_class' object has no attribute 
> 'blah_blah'...
> 488 """
> --> 489 return self.getattr_from_category(name)
> 490 
> 491 cdef getattr_from_category(self, name) noexcept:
>
> File ~/sage/sage/src/sage/structure/element.pyx:502, in 
> sage.structure.element.Element.getattr_from_category()
> 500 else:
> 501 cls = P._abstract_element_class
> --> 502 return getattr_from_other_class(self, cls, name)
> 503 
> 504 def __dir__(self):
>
> File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
> sage.cpython.getattr.getattr_from_other_class()
> 355 dummy_error_message.cls = type(self)
> 356 dummy_error_message.name = name
> --> 357 raise AttributeError(dummy_error_message)
> 358 cdef PyObject* attr = instance_getattr(cls, name)
> 359 if attr is NULL:
>
> AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' object 
> has no attribute 'degree'
>
> On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:
>
>> 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 writing randomised testing I got myself confused about the degree 
>>> of the zero polynomial. For the univariate and multivariate polynomial 
>>> rings, we currently use that the degree for 0 (both R(0).degree() as well 
>>> as R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>>>
>>> However for the LaurentPolynomialRings, a polynomial with negative 
>>> valuation is very natural. For example the following code snippet shows the 
>>> ambiguity.
>>>
>>> sage: L. = LaurentPolynomialRing(QQ)
>>> sage: f = (1/x); f
>>> x^-1
>>> sage: f.degree()
>>> -1
>>> sage: L.zero().degree()
>>> -1
>>>
>>> I don't feel familiar enough with the mathematics here and the usual use 
>>> cases in sage to offer a PR "fixing" this, or whether it even needs fixing. 
>>> However, I got confused so I thought maybe others might get confused and 
>>> someone on this list might have a suggestion.
>>>
>>> I think the "usual" suggestion would be to have the degree as -infty, 
>>> but then there's a question about whether this should be done for other 
>>> polynomial rings...
>>>
>>> I made an issue for this on GitHub too:
>>>
>>> https://github.com/sagemath/sage/issues/37491
>>>
>>

-- 
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/c9c805f9-fbd0-4591-8729-002f3ad90fa1n%40googlegroups.com.

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

This is not what I see on the current beta:

sage: R. = LaurentSeriesRing(QQ)
sage: R.zero().degree()
-1
sage: R. = LazyLaurentSeriesRing(QQ)
sage: R.zero().degree()
---
AttributeErrorTraceback (most recent call last)
Cell In[4], line 1
> 1 R.zero().degree()

File ~/sage/sage/src/sage/structure/element.pyx:489, in 
sage.structure.element.Element.__getattr__()
487 AttributeError: 
'LeftZeroSemigroup_with_category.element_class' object has no attribute 
'blah_blah'...
488 """
--> 489 return self.getattr_from_category(name)
490 
491 cdef getattr_from_category(self, name) noexcept:

File ~/sage/sage/src/sage/structure/element.pyx:502, in 
sage.structure.element.Element.getattr_from_category()
500 else:
501 cls = P._abstract_element_class
--> 502 return getattr_from_other_class(self, cls, name)
503 
504 def __dir__(self):

File ~/sage/sage/src/sage/cpython/getattr.pyx:357, in 
sage.cpython.getattr.getattr_from_other_class()
355 dummy_error_message.cls = type(self)
356 dummy_error_message.name = name
--> 357 raise AttributeError(dummy_error_message)
358 cdef PyObject* attr = instance_getattr(cls, name)
359 if attr is NULL:

AttributeError: 'LazyLaurentSeriesRing_with_category.element_class' object 
has no attribute 'degree'

On Wednesday, February 28, 2024 at 12:05:32 PM UTC Martin R wrote:

> 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 writing randomised testing I got myself confused about the degree of 
>> the zero polynomial. For the univariate and multivariate polynomial rings, 
>> we currently use that the degree for 0 (both R(0).degree() as well as 
>> R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>>
>> However for the LaurentPolynomialRings, a polynomial with negative 
>> valuation is very natural. For example the following code snippet shows the 
>> ambiguity.
>>
>> sage: L. = LaurentPolynomialRing(QQ)
>> sage: f = (1/x); f
>> x^-1
>> sage: f.degree()
>> -1
>> sage: L.zero().degree()
>> -1
>>
>> I don't feel familiar enough with the mathematics here and the usual use 
>> cases in sage to offer a PR "fixing" this, or whether it even needs fixing. 
>> However, I got confused so I thought maybe others might get confused and 
>> someone on this list might have a suggestion.
>>
>> I think the "usual" suggestion would be to have the degree as -infty, but 
>> then there's a question about whether this should be done for other 
>> polynomial rings...
>>
>> I made an issue for this on GitHub too:
>>
>> https://github.com/sagemath/sage/issues/37491
>>
>

-- 
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/e245cd6a-a18b-4d72-bf55-d55d8d699d5dn%40googlegroups.com.

[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 
> 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]], sparse=True)
> sage: b = vector(GF(3), [1], sparse=True)
> sage: m.solve_right(b)
> ---
> TypeError Traceback (most recent call last)
> Cell In[157], line 1
> > 1 m.solve_right(b)
>
> File ~/sage/src/sage/matrix/matrix2.pyx:942, in 
> sage.matrix.matrix2.Matrix.solve_right()
> 940 else:
> 941 try:
> --> 942 X = self._solve_right_nonsingular_square(C, 
> check_rank=True)
> 943 except NotFullRankError:
> 944 X = self._solve_right_general(C, check=check)
>
> File ~/sage/src/sage/matrix/matrix_modn_sparse.pyx:948, in 
> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse._solve_right_nonsingular_square()
> 946 if isinstance(B, Matrix):
> 947 from sage.matrix.special import diagonal_matrix
> --> 948 m, d = self._solve_matrix_linbox(B, algorithm)
> 949 return m  * diagonal_matrix([QQ((1,x)) for x in d])
> 950 else:
>
> File ~/sage/src/sage/matrix/matrix_modn_sparse.pyx:1132, in 
> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse._solve_matrix_linbox()
>1130 
>1131 cdef givaro.ZRing givZZ
> -> 1132 cdef linbox.SparseMatrix_integer * A = 
> new_linbox_matrix_integer_sparse(givZZ, self)
>1133 cdef linbox.DenseVector_integer * b = new 
> linbox.DenseVector_integer(givZZ,  self._nrows)
>1134 cdef linbox.DenseVector_integer * res = new 
> linbox.DenseVector_integer(givZZ,  self._ncols)
>
> TypeError: Cannot convert 
> sage.matrix.matrix_modn_sparse.Matrix_modn_sparse to 
> sage.matrix.matrix_integer_sparse.Matrix_integer_sparse
>
>

-- 
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/f2ffb1a6-3a10-4814-a46c-2fc7b938a500n%40googlegroups.com.

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

I went through the link.
It also returns perm_c and perm_r and the solution is represented as

Pr * (R^-1) * A * Pc = L * U

It is similar to one returned by scipy
>>> lu.perm_r

   array([0, 2, 1, 3], dtype=int32)

>>> lu.perm_c

   array([2, 0, 1, 3], dtype=int32)

I think it doesn't support square matrix too. Link 

On Wednesday, February 28, 2024 at 6:17:26 PM UTC+5:30 Max Alekseyev wrote:

> One more option would be umfack via scikits.umfpack:
>
> https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html
>
> Regards,
> Max
> On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree wrote:
>
>> One thing I would like to suggest.
>>
>> We can provide multiple ways to compute the sparse LU
>> 1. scipy 
>> 2. sage original implementation in src.sage.matrix.matrix2.LU 
>> 
>>  (Note 
>> - link 
>> 
>> )
>> 3. convert to dense then factor
>>
>> It will be up to user to choose based on the complexity.
>> Is it fine?
>>
>> On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree 
>> wrote:
>>
>>> Thank you for reminding
>>> I went through. 
>>> We need to Decompose  A11 only and rest can be calculated via taking 
>>> inverse of L11 or U11.
>>> Here A11 is square matrix and we can use scipy to decompose square 
>>> matrices.
>>> Am I correct?
>>>
>>> New and only problem that I see is the returned LU decomposition of 
>>> scipy's splu is calculated by full permutation of row and column as pointed 
>>> out by *Nils Bruin*. We will be returning row and col permutation 
>>> array/matrix separately 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 
>>> & p={perm_r, perm_c}
>>> or
>>> We can leave that to user
>>> User will have to permute its input data according to perm_c (like : 
>>> perm_c * input) before using the perm_r^(-1) * L * U
>>> as perm_r^(-1) * L * U is PLU decomposition of Original_matrix*perm_c
>>>
>>> https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html
>>> >>> A = Pr^(-1) *L*U * Pc^(-1) # as told by *Nils Bruin*
>>> or
>>> scipy's splu will not do.
>>>
>>> On Tuesday, February 27, 2024 at 11:57:02 PM UTC+5:30 Dima Pasechnik 
>>> wrote:
>>>


 On 27 February 2024 17:25:51 GMT, 'Animesh Shree' via sage-devel <
 sage-...@googlegroups.com> wrote: 
 >This works good if input is square and I also checked on your idea of 
 >padding zeros for non square matrices. 
 >I am currently concerned about the permutation matrix and L, U in case 
 of 
 >padded 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: 
 > 
 >> 
 >> 
 >> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel < 
 >> sage-...@googlegroups.com> wrote: 
 >> >I tried scipy which uses superLU. We get the result but there is 
 little 
 >> bit 
 >> >of issue. 
 >> > 
 >> > 
 >> >--For Dense-- 
 >> >The dense matrix factorization gives this output using permutation 
 matrix 
 >> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True) 
 >> >sage: a 
 >> >[1.0 0.0] 
 >> >[2.0 1.0] 
 >> >sage: p,l,u = a.dense_matrix().LU() 
 >> >sage: p 
 >> >[0.0 1.0] 
 >> >[1.0 0.0] 
 >> >sage: l 
 >> >[1.0 0.0] 
 >> >[0.5 1.0] 
 >> >sage: u 
 >> >[ 2.0 1.0] 
 >> >[ 0.0 -0.5] 
 >> > 
 >> 
 >> you'd probably want to convert the permutation matrix into a 
 permutation. 
 >> 
 >> 
 >> >--For Sparse-- 
 >> >But the scipy LU decomposition uses permutations which involves 
 taking 
 >> >transpose, also the output permutations are represented as array. 
 >> 
 >> It is very normal to represent permutations as arrays. 
 >> One can reconstruct the permutation matrix from such an array 
 trivially 
 >> (IIRC, Sage even has a function for it) 
 >> 
 >> I am not sure what you mean by "taking transpose". 
 >> 
 >> >sage: p,l,u = a.LU(force=True) 
 >> >sage: p 
 >> >{'perm_r': [1, 0], 'perm_c': [1, 0]} 
 >> >sage: l 
 >> >[1.0 0.0] 
 >> >[0.0 1.0] 
 >> >sage: u 
 >> >[1.0 2.0] 
 >> >[0.0

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

2024-02-28 Thread Max Alekseyev

One more option would be umfack via scikits.umfpack:
https://scikit-umfpack.github.io/scikit-umfpack/reference/scikits.umfpack.UmfpackLU.html

Regards,
Max
On Wednesday, February 28, 2024 at 7:07:53 AM UTC-5 Animesh Shree wrote:

> One thing I would like to suggest.
>
> We can provide multiple ways to compute the sparse LU
> 1. scipy 
> 2. sage original implementation in src.sage.matrix.matrix2.LU 
> 
>  (Note 
> - link 
> 
> )
> 3. convert to dense then factor
>
> It will be up to user to choose based on the complexity.
> Is it fine?
>
> On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree wrote:
>
>> Thank you for reminding
>> I went through. 
>> We need to Decompose  A11 only and rest can be calculated via taking 
>> inverse of L11 or U11.
>> Here A11 is square matrix and we can use scipy to decompose square 
>> matrices.
>> Am I correct?
>>
>> New and only problem that I see is the returned LU decomposition of 
>> scipy's splu is calculated by full permutation of row and column as pointed 
>> out by *Nils Bruin*. We will be returning row and col permutation 
>> array/matrix separately 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 & 
>> p={perm_r, 
>> perm_c}
>> or
>> We can leave that to user
>> User will have to permute its input data according to perm_c (like : 
>> perm_c * input) before using the perm_r^(-1) * L * U
>> as perm_r^(-1) * L * U is PLU decomposition of Original_matrix*perm_c
>>
>> https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html
>> >>> A = Pr^(-1) *L*U * Pc^(-1) # as told by *Nils Bruin*
>> or
>> scipy's splu will not do.
>>
>> On Tuesday, February 27, 2024 at 11:57:02 PM UTC+5:30 Dima Pasechnik 
>> wrote:
>>
>>>
>>>
>>> On 27 February 2024 17:25:51 GMT, 'Animesh Shree' via sage-devel <
>>> sage-...@googlegroups.com> wrote: 
>>> >This works good if input is square and I also checked on your idea of 
>>> >padding zeros for non square matrices. 
>>> >I am currently concerned about the permutation matrix and L, U in case 
>>> of 
>>> >padded 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: 
>>> > 
>>> >> 
>>> >> 
>>> >> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel < 
>>> >> sage-...@googlegroups.com> wrote: 
>>> >> >I tried scipy which uses superLU. We get the result but there is 
>>> little 
>>> >> bit 
>>> >> >of issue. 
>>> >> > 
>>> >> > 
>>> >> >--For Dense-- 
>>> >> >The dense matrix factorization gives this output using permutation 
>>> matrix 
>>> >> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True) 
>>> >> >sage: a 
>>> >> >[1.0 0.0] 
>>> >> >[2.0 1.0] 
>>> >> >sage: p,l,u = a.dense_matrix().LU() 
>>> >> >sage: p 
>>> >> >[0.0 1.0] 
>>> >> >[1.0 0.0] 
>>> >> >sage: l 
>>> >> >[1.0 0.0] 
>>> >> >[0.5 1.0] 
>>> >> >sage: u 
>>> >> >[ 2.0 1.0] 
>>> >> >[ 0.0 -0.5] 
>>> >> > 
>>> >> 
>>> >> you'd probably want to convert the permutation matrix into a 
>>> permutation. 
>>> >> 
>>> >> 
>>> >> >--For Sparse-- 
>>> >> >But the scipy LU decomposition uses permutations which involves 
>>> taking 
>>> >> >transpose, also the output permutations are represented as array. 
>>> >> 
>>> >> It is very normal to represent permutations as arrays. 
>>> >> One can reconstruct the permutation matrix from such an array 
>>> trivially 
>>> >> (IIRC, Sage even has a function for it) 
>>> >> 
>>> >> I am not sure what you mean by "taking transpose". 
>>> >> 
>>> >> >sage: p,l,u = a.LU(force=True) 
>>> >> >sage: p 
>>> >> >{'perm_r': [1, 0], 'perm_c': [1, 0]} 
>>> >> >sage: l 
>>> >> >[1.0 0.0] 
>>> >> >[0.0 1.0] 
>>> >> >sage: u 
>>> >> >[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 block matrix 
>>> >> >> A11 A12 
>>> >> >> A21 A22 
>>> >> >> 
>>> >> >> then its LU-factors L and U are 
>>> >> >> L11 0 and U11 U12 
>>> >> >> L21 L22 0 U22 
>>> >> >> 
>>> >> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22 
>>> >> >> 
>>> >> >> Assume that A11 is square and full rank (else one may apply 
>>> >>

[sage-devel] Re: Poll: deprecate backslash operator

2024-02-28 Thread Max Alekseyev

Here is another bug apparently related to the preparser and "\":
https://github.com/sagemath/sage/issues/37467

Regards,
Max

On Wednesday, October 4, 2023 at 1:01:54 AM UTC-4 John H Palmieri wrote:

> By the way, see https://github.com/sagemath/sage/issues/36194 for a bug 
> related to the preparser and "\".
>
> On Tuesday, October 3, 2023 at 9:59:47 PM UTC-7 John H Palmieri wrote:
>
>> The votes are overwhelmingly in favor of deprecating. I have opened 
>> https://github.com/sagemath/sage/pull/36394 for this.
>>
>>
>> On Monday, October 2, 2023 at 3:42:38 AM UTC-7 kcrisman wrote:
>>
>>> Though I am sympathetic to the pro-deprecation arguments and recognize 
>>> they will win, I vote do not deprecate, as mission includes Matlab, and for 
>>> backwards compatibility.  As an example, the first edition of the 
>>> AMS-published "Sage for Undergraduates" used the backslash operator in a 
>>> number of examples (comparing it explicitly with other solving methods for 
>>> linear systems), so I presume the second edition has maintained that 
>>> (though I don't personally own it and can't verify immediately; a related 
>>> website does not seem to have all code examples).
>>>
>>> On Sunday, October 1, 2023 at 6:59:39 AM UTC-4 Ricardo Buring wrote:
>>>
 Deprecate the pre-parsing of \
 the backslash operator please.



-- 
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/a18e7eae-4d78-4306-b73b-0d345e4bb32fn%40googlegroups.com.

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

One thing I would like to suggest.

We can provide multiple ways to compute the sparse LU
1. scipy 
2. sage original implementation in src.sage.matrix.matrix2.LU 

 (Note 
- link 

)
3. convert to dense then factor

It will be up to user to choose based on the complexity.
Is it fine?

On Wednesday, February 28, 2024 at 4:30:51 PM UTC+5:30 Animesh Shree wrote:

> Thank you for reminding
> I went through. 
> We need to Decompose  A11 only and rest can be calculated via taking 
> inverse of L11 or U11.
> Here A11 is square matrix and we can use scipy to decompose square 
> matrices.
> Am I correct?
>
> New and only problem that I see is the returned LU decomposition of 
> scipy's splu is calculated by full permutation of row and column as pointed 
> out by *Nils Bruin*. We will be returning row and col permutation 
> array/matrix separately 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 & 
> p={perm_r, 
> perm_c}
> or
> We can leave that to user
> User will have to permute its input data according to perm_c (like : 
> perm_c * input) before using the perm_r^(-1) * L * U
> as perm_r^(-1) * L * U is PLU decomposition of Original_matrix*perm_c
>
> https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.SuperLU.html
> >>> A = Pr^(-1) *L*U * Pc^(-1) # as told by *Nils Bruin*
> or
> scipy's splu will not do.
>
> On Tuesday, February 27, 2024 at 11:57:02 PM UTC+5:30 Dima Pasechnik wrote:
>
>>
>>
>> On 27 February 2024 17:25:51 GMT, 'Animesh Shree' via sage-devel <
>> sage-...@googlegroups.com> wrote: 
>> >This works good if input is square and I also checked on your idea of 
>> >padding zeros for non square matrices. 
>> >I am currently concerned about the permutation matrix and L, U in case 
>> of 
>> >padded 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: 
>> > 
>> >> 
>> >> 
>> >> On 27 February 2024 15:34:20 GMT, 'Animesh Shree' via sage-devel < 
>> >> sage-...@googlegroups.com> wrote: 
>> >> >I tried scipy which uses superLU. We get the result but there is 
>> little 
>> >> bit 
>> >> >of issue. 
>> >> > 
>> >> > 
>> >> >--For Dense-- 
>> >> >The dense matrix factorization gives this output using permutation 
>> matrix 
>> >> >sage: a = Matrix(RDF, [[1, 0],[2, 1]], sparse=True) 
>> >> >sage: a 
>> >> >[1.0 0.0] 
>> >> >[2.0 1.0] 
>> >> >sage: p,l,u = a.dense_matrix().LU() 
>> >> >sage: p 
>> >> >[0.0 1.0] 
>> >> >[1.0 0.0] 
>> >> >sage: l 
>> >> >[1.0 0.0] 
>> >> >[0.5 1.0] 
>> >> >sage: u 
>> >> >[ 2.0 1.0] 
>> >> >[ 0.0 -0.5] 
>> >> > 
>> >> 
>> >> you'd probably want to convert the permutation matrix into a 
>> permutation. 
>> >> 
>> >> 
>> >> >--For Sparse-- 
>> >> >But the scipy LU decomposition uses permutations which involves 
>> taking 
>> >> >transpose, also the output permutations are represented as array. 
>> >> 
>> >> It is very normal to represent permutations as arrays. 
>> >> One can reconstruct the permutation matrix from such an array 
>> trivially 
>> >> (IIRC, Sage even has a function for it) 
>> >> 
>> >> I am not sure what you mean by "taking transpose". 
>> >> 
>> >> >sage: p,l,u = a.LU(force=True) 
>> >> >sage: p 
>> >> >{'perm_r': [1, 0], 'perm_c': [1, 0]} 
>> >> >sage: l 
>> >> >[1.0 0.0] 
>> >> >[0.0 1.0] 
>> >> >sage: u 
>> >> >[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 block matrix 
>> >> >> A11 A12 
>> >> >> A21 A22 
>> >> >> 
>> >> >> then its LU-factors L and U are 
>> >> >> L11 0 and U11 U12 
>> >> >> L21 L22 0 U22 
>> >> >> 
>> >> >> and A11=L11 U11, A12=L11 U12, A21=L21 U11, A22=L21 U12+L22 U22 
>> >> >> 
>> >> >> Assume that A11 is square and full rank (else one may apply 
>> >> >> permutations of rows and columns in the usual way). while A21=0 and 
>> >> >> A22=0. Then one can take L21=0, L22=U22=0, while A12=L11 U12 
>> >> >> implies U12=L11^-1 A12. 
>> >> >> That is, we can first compute LU-decomposition of a square matrix 
>> A11, 
>> >> >> and then compute U12 from it and A. 
>> >> >> 
>> >> >> Similarly, if instead A12=0 and A22=0, then we can take U12=0,

[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 writing randomised testing I got myself confused about the degree of 
> the zero polynomial. For the univariate and multivariate polynomial rings, 
> we currently use that the degree for 0 (both R(0).degree() as well as 
> R(0).degree(x)) is -1. This is unambiguous for the case of these types.
>
> However for the LaurentPolynomialRings, a polynomial with negative 
> valuation is very natural. For example the following code snippet shows the 
> ambiguity.
>
> sage: L. = LaurentPolynomialRing(QQ)
> sage: f = (1/x); f
> x^-1
> sage: f.degree()
> -1
> sage: L.zero().degree()
> -1
>
> I don't feel familiar enough with the mathematics here and the usual use 
> cases in sage to offer a PR "fixing" this, or whether it even needs fixing. 
> However, I got confused so I thought maybe others might get confused and 
> someone on this list might have a suggestion.
>
> I think the "usual" suggestion would be to have the degree as -infty, but 
> then there's a question about whether this should be done for other 
> polynomial rings...
>
> I made an issue for this on GitHub too:
>
> https://github.com/sagemath/sage/issues/37491
>

-- 
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/8ee98f5b-0502-461f-9b6c-c7e588ed062en%40googlegroups.com.

[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]], sparse=True)
sage: b = vector(GF(3), [1], sparse=True)
sage: m.solve_right(b)
---
TypeError Traceback (most recent call last)
Cell In[157], line 1
> 1 m.solve_right(b)

File ~/sage/src/sage/matrix/matrix2.pyx:942, in 
sage.matrix.matrix2.Matrix.solve_right()
940 else:
941 try:
--> 942 X = self._solve_right_nonsingular_square(C, check_rank=True)
943 except NotFullRankError:
944 X = self._solve_right_general(C, check=check)

File ~/sage/src/sage/matrix/matrix_modn_sparse.pyx:948, in 
sage.matrix.matrix_modn_sparse.Matrix_modn_sparse._solve_right_nonsingular_square()
946 if isinstance(B, Matrix):
947 from sage.matrix.special import diagonal_matrix
--> 948 m, d = self._solve_matrix_linbox(B, algorithm)
949 return m  * diagonal_matrix([QQ((1,x)) for x in d])
950 else:

File ~/sage/src/sage/matrix/matrix_modn_sparse.pyx:1132, in 
sage.matrix.matrix_modn_sparse.Matrix_modn_sparse._solve_matrix_linbox()
   1130 
   1131 cdef givaro.ZRing givZZ
-> 1132 cdef linbox.SparseMatrix_integer * A = 
new_linbox_matrix_integer_sparse(givZZ, self)
   1133 cdef linbox.DenseVector_integer * b = new 
linbox.DenseVector_integer(givZZ,  self._nrows)
   1134 cdef linbox.DenseVector_integer * res = new 
linbox.DenseVector_integer(givZZ,  self._ncols)

TypeError: Cannot convert sage.matrix.matrix_modn_sparse.Matrix_modn_sparse 
to sage.matrix.matrix_integer_sparse.Matrix_integer_sparse

-- 
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/ea0ba4cf-83ce-4d85-a742-d5cbb8c4d116n%40googlegroups.com.

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

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 writing randomised testing I got myself confused about the degree of
the zero polynomial. For the univariate and multivariate polynomial rings,
we currently use that the degree for 0 (both R(0).degree() as well as
R(0).degree(x)) is -1. This is unambiguous for the case of these types.

However for the LaurentPolynomialRings, a polynomial with negative
valuation is very natural. For example the following code snippet shows the
ambiguity.

sage: L. = LaurentPolynomialRing(QQ)
sage: f = (1/x); f
x^-1
sage: f.degree()
-1
sage: L.zero().degree()
-1

I don't feel familiar enough with the mathematics here and the usual use
cases in sage to offer a PR "fixing" this, or whether it even needs fixing.
However, I got confused so I thought maybe others might get confused and
someone on this list might have a suggestion.

I think the "usual" suggestion would be to have the degree as -infty, but
then there's a question about whether this should be done for other
polynomial rings...

I made an issue for this on GitHub too:

https://github.com/sagemath/sage/issues/37491

--
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/0efa0dd8-b322-4896-b9af-a88effeaa195n%40googlegroups.com.

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

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 uncovered 
(usually) trivial bugs. I then write new PRs to fix these bugs.

If there is code causing CI failure in random testing, should I mark the 
fix for this as a "blocker", even if the chance of this failure is small? I 
don't want to be melodramatic in my PR for fixes but I also want to make 
sure I'm labelling things as expected,

On Wednesday, February 28, 2024 at 6:08:20 AM UTC David Roe wrote:

> On Wed, Feb 28, 2024 at 1:01 AM Kwankyu Lee  wrote:
>
>> Thank you for making progress on these urgent issues. I suggest the 
>> following:
>>
>> 1. Open two other new threads, each of which is for voting on each 
>> proposal. 
>> 2. On a proposal, it should be clear that *a positive vote (+1) is for 
>> the whole proposal,* and if one is negative to any part of the proposal, 
>> (s)he should give a negative vote (-1).  
>>
>
> Voting threads seem reasonable.  I'll wait a day or two to see if people 
> have any final comments before voting.
>  
>
>> 3. A proposal is accepted if the number of positive votes is at least 
>> twice of the number of the negative votes.
>>
>
> Despite the fact that we're asking for this threshold in voting on a PR, 
> the standard for votes on proposals on sage-devel is just a plain majority 
> (though of course I hope that we can come to a 2-1 consensus!).
>
> A minor suggestion for Proposal 2: for the label to be readable, I suggest 
>> "CI fix" for the name of the label (a blank between words). 
>>
>
> I'm happy to adjust the label to be "CI fix."
>  
>
>> We may use this thread to get more comments on the Proposals before 
>> opening voting threads.
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/554961a0-4ace-4317-bfcf-55b6a128bcden%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/b84b22d2-9b57-460c-9f8d-5f8ebe2f982en%40googlegroups.com.

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