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

[Nils Bruin]

On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:

How about using something like https://github.com/NeilGirdhar/extended_int ?
(Even better, do a PEP to have such a thing in Python proper...)
In old, totally duck-typed, Python this didn't really matter, but nowadays 
it does make
a perfect sense.

At the moment, I think most degree functions do their best to return sage 
Integer objects; mainly so that coercion works well with them. So whatever 
solution we use should probably be based on objects that naturally live in 
the sage hierarchy. We do have an infinity object in sage and it already 
gets used for valuations.

Incidentally:

 sage: R.=LaurentSeriesRing(QQ)
sage: z=R(0)
sage: z.valuation()
+Infinity
sage: z.degree()
-1

I don't quite know why laurent series have a degree defined at all, but 
they're keeping to the deg(0)=-1 convention. 

Incidentally:

sage: A.=QQ[]
sage: B.=LaurentPolynomialRing(QQ)
sage: x.valuation(oo)
-1
sage: y.valuation(oo)
1
so polynomial rings have a valuation (that will return +oo when 
appropriate), but on LaurentPolynomialRing this gets silently broken: the 
argument simply gets ignored and the valuation at 0 is returned. So I guess 
you can get a well-behaving degree with

f=0*y
-f(1/y).valuation()

-- 
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/053266d4-6fa6-4ac4-8ea0-61a3bf136758n%40googlegroups.com.

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

[Dima Pasechnik]

On Thu, Feb 29, 2024 at 4:34 PM Oscar Benjamin 
wrote:

> I recently reviewed cases in the sympy polys code that handle the
> degree of a zero polynomial:
> https://github.com/sympy/sympy/pull/25784
>
> My conclusion is that it is sometimes useful that deg(0) < deg(p) for
> p != 0 but otherwise it is not really possible to use the value of
> deg(0) for anything meaningful in practice. Generally if deg(p) is
> needed then the zero polynomial needs special handling that no
> particular value of deg(0) helps with. I would prefer that deg(0) = -1
> just so that the deg() function has a well defined type.
>

How about using something like https://github.com/NeilGirdhar/extended_int ?
(Even better, do a PEP to have such a thing in Python proper...)
In old, totally duck-typed, Python this didn't really matter, but nowadays
it does make
a perfect sense.


>
> For Laurent polynomials I am not sure that I would define a degree()
> method or if I did that it would be defined as the exponent of the
> leading term. It isn't clear to me when that notion of degree would be
> useful: it doesn't seem like it would generalise the ways that degree
> is  typically used for ordinary polynomials.
>
> On Thu, 29 Feb 2024 at 10:57, Giacomo Pope  wrote:
> >
> > There seem to be two things we could do here:
> >
> > 1. Have some form of vote / discussion on whether the degree of the zero
> polynomial should *ever* be -1
> > 2. Modify the degree calls for the LaurentSeries and
> LaurentPolynomialRing (maybe other Laurent* which I am unfamiliar with) to
> have the zero polynomial have degree -Infinity.
> >
> > Option 1 may be cleaner in the long run, but I assume will cause issues
> for more people in the short term. Option 2 seems fairly harmless and
> there's no good argument for degree -1 in this case.
> >
> > If anyone is interested in option 2, I will find time to make a PR to do
> this, but I will not start this work without other people's input as this
> is not code I am familiar with using and so I don't know what people could
> be relying on.
> > On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote:
> >>
> >> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin  wrote:
> >>>
> >>> 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+...@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/6d95b253-fb17-4e2f-a61c-c723737774e8n%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/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%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/CAAWYfq2n-Zg02OpJZHOjPsRY9fbZx%3DqCjya3%3DPpRVNNSx_FBqA%40mail.gmail.com.

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

[John Cremona]

There may be case for leaving deg(0) undefined both for polynomials and
Laurent polynomials (and power series and Laurent series): it's at best a
shorthand (pace Nils' comment about dimensions) and needs to be handled
separately in code.  So calling deg(0) could raise a ValueError or
ArithmeticError (just as "factor(0)" does)?

John

On Thu, 29 Feb 2024 at 16:34, Oscar Benjamin 
wrote:

> I recently reviewed cases in the sympy polys code that handle the
> degree of a zero polynomial:
> https://github.com/sympy/sympy/pull/25784
>
> My conclusion is that it is sometimes useful that deg(0) < deg(p) for
> p != 0 but otherwise it is not really possible to use the value of
> deg(0) for anything meaningful in practice. Generally if deg(p) is
> needed then the zero polynomial needs special handling that no
> particular value of deg(0) helps with. I would prefer that deg(0) = -1
> just so that the deg() function has a well defined type.
>
> For Laurent polynomials I am not sure that I would define a degree()
> method or if I did that it would be defined as the exponent of the
> leading term. It isn't clear to me when that notion of degree would be
> useful: it doesn't seem like it would generalise the ways that degree
> is  typically used for ordinary polynomials.
>
> On Thu, 29 Feb 2024 at 10:57, Giacomo Pope  wrote:
> >
> > There seem to be two things we could do here:
> >
> > 1. Have some form of vote / discussion on whether the degree of the zero
> polynomial should *ever* be -1
> > 2. Modify the degree calls for the LaurentSeries and
> LaurentPolynomialRing (maybe other Laurent* which I am unfamiliar with) to
> have the zero polynomial have degree -Infinity.
> >
> > Option 1 may be cleaner in the long run, but I assume will cause issues
> for more people in the short term. Option 2 seems fairly harmless and
> there's no good argument for degree -1 in this case.
> >
> > If anyone is interested in option 2, I will find time to make a PR to do
> this, but I will not start this work without other people's input as this
> is not code I am familiar with using and so I don't know what people could
> be relying on.
> > On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote:
> >>
> >> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin  wrote:
> >>>
> >>> 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+...@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/6d95b253-fb17-4e2f-a61c-c723737774e8n%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/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%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 

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

[Matthias Koeppe]

-1 

For the most part, because this proposed policy cannot be reflected in the 
GitHub user interface: 
The list of selectable labels in the drop down menu cannot depend on 
whether it's an Issue or a PR.

Matthias

On Tuesday, February 27, 2024 at 10:45:03 PM UTC-8 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.
> 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/4c3cb94a-10b2-470b-9e42-0661548f4f67n%40googlegroups.com.

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

[Oscar Benjamin]

I recently reviewed cases in the sympy polys code that handle the
degree of a zero polynomial:
https://github.com/sympy/sympy/pull/25784

My conclusion is that it is sometimes useful that deg(0) < deg(p) for
p != 0 but otherwise it is not really possible to use the value of
deg(0) for anything meaningful in practice. Generally if deg(p) is
needed then the zero polynomial needs special handling that no
particular value of deg(0) helps with. I would prefer that deg(0) = -1
just so that the deg() function has a well defined type.

For Laurent polynomials I am not sure that I would define a degree()
method or if I did that it would be defined as the exponent of the
leading term. It isn't clear to me when that notion of degree would be
useful: it doesn't seem like it would generalise the ways that degree
is  typically used for ordinary polynomials.

On Thu, 29 Feb 2024 at 10:57, Giacomo Pope  wrote:
>
> There seem to be two things we could do here:
>
> 1. Have some form of vote / discussion on whether the degree of the zero 
> polynomial should *ever* be -1
> 2. Modify the degree calls for the LaurentSeries and LaurentPolynomialRing 
> (maybe other Laurent* which I am unfamiliar with) to have the zero polynomial 
> have degree -Infinity.
>
> Option 1 may be cleaner in the long run, but I assume will cause issues for 
> more people in the short term. Option 2 seems fairly harmless and there's no 
> good argument for degree -1 in this case.
>
> If anyone is interested in option 2, I will find time to make a PR to do 
> this, but I will not start this work without other people's input as this is 
> not code I am familiar with using and so I don't know what people could be 
> relying on.
> On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote:
>>
>> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin  wrote:
>>>
>>> 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+...@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/6d95b253-fb17-4e2f-a61c-c723737774e8n%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/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%40mail.gmail.com.

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

['Animesh Shree' via sage-devel]

Ok, I will do the same.

On Thursday, February 29, 2024 at 12:11:56 AM UTC+5:30 Dima Pasechnik wrote:

> On Wed, Feb 28, 2024 at 5:42 PM 'Animesh Shree' via sage-devel <
> sage-...@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 

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

[kcrisman]

On Wednesday, February 28, 2024 at 1:45:03 AM UTC-5 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.


I appreciate the spirit of this request, but since Trac did not distinguish 
between issues and PRs and we used blocker regularly on Trac, it seems like 
a pretty big change, and sort of implies you can't block a release (in 
principle) even with some big problem if you can't contribute a fix 
immediately. -1 for now.

-- 
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/255e9f64-9bd5-468c-b8e3-0d56ea2aa00an%40googlegroups.com.

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

[Giacomo Pope]

There seem to be two things we could do here:

1. Have some form of vote / discussion on whether the degree of the zero 
polynomial should *ever* be -1
2. Modify the degree calls for the LaurentSeries and LaurentPolynomialRing 
(maybe other Laurent* which I am unfamiliar with) to have the zero 
polynomial have degree -Infinity.

Option 1 may be cleaner in the long run, but I assume will cause issues for 
more people in the short term. Option 2 seems fairly harmless and there's 
no good argument for degree -1 in this case.

If anyone is interested in option 2, I will find time to make a PR to do 
this, but I will not start this work without other people's input as this 
is not code I am familiar with using and so I don't know what people could 
be relying on.
On Wednesday, February 28, 2024 at 6:41:48 PM UTC Dima Pasechnik wrote:

> On Wed, Feb 28, 2024 at 5:00 PM Nils Bruin  wrote:
>
>> 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+...@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/6d95b253-fb17-4e2f-a61c-c723737774e8n%40googlegroups.com.