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

[John Cremona]

Mathematically, the degree of a nonzero polynomial is the negative of  its
valuation at infinity, i.e. the valuation for which 1/x is a uniformiser.

On Fri, 1 Mar 2024, 19:29 Travis Scrimshaw,  wrote:

> Some quick data points:
>
> - The general graded modules (and hence algebras) code raises an error for
> `0` since it is defined there by the direct summand the element belongs to
> (and `0` belongs to all of them.
> - For polynomials, it is very useful to have a single check `f.degree() >
> k` for some `k`. Having error messages or check `f.is_zero()` first makes
> things more complicated.
> - Comparisons of integers to `-infinity` is (relatively) expensive.
> Although this happening frequently seems unlikely.
>
> Martin, note that Dima is calling degree with a min/max qualifier added in
> front. I think this is leading to some confusion and cross-talk. However, I
> think it is better to have easily separable terms "valuation" and "degree"
> (which exist for polynomials).
>
> Best,
> Travis
>
> On Saturday, March 2, 2024 at 3:44:55 AM UTC+9 Martin R wrote:
>
>> I don't get it - are my previous messages invisible?
>>
>> 1st Message: I don't understand - `degree` doesn't make much sense for
>> Laurent series - there is no way to determine the degree of a LaurentSeries
>> and no way to determine the degree of a LazyLaurentSeries with one minor
>> exception - which is when it is known that the series terminates, but
>> that's rare.
>>
>> 2nd Message: I am very much against this.  I realise that this is a
>> convention one uses in mathematics, but here it would be extremely
>> confusing: in the lazy series code we use valuation a lot, and it must mean
>> lowest degree, but we also use the degree of polynomials and Laurent
>> polynomials and we must distinguish between the two.
>>
>> I feel a bit ignored,
>>
>> Martin
>>
>>
>> On Friday 1 March 2024 at 19:29:26 UTC+1 Giacomo Pope wrote:
>>
>> As an aside, the univariate LaurentPolynomialRing had a notion of
>> `valuation` but the multivariate one didn't...
>>
>> In the PR: https://github.com/sagemath/sage/pull/37490 I added random
>> elements but also a notion of valuation() for the multivariate case and
>> just made it act similarly to the univariate one.
>>
>> On Friday, March 1, 2024 at 6:18:01 PM UTC Nils Bruin wrote:
>>
>> On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:
>>
>> Following this discussion, I have made a draft PR to change the degree
>> for *only* the LaurentPolynomialRing and I will see if the CI detects
>> anything.
>>
>> https://github.com/sagemath/sage/pull/37513
>>
>> I agree that if we change the LaurentPolynomialRing we should also change
>> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no
>> method `degree()` but *does* have a `valuation()` method... so this is odd.
>>
>>
>> OK, let's keep it that way then! I don't think there is a notion on
>> LaurentSeriesRing that deserves the name "degree". Sorry about mixing that
>> one in. I thought it existed. And I think it does:
>>
>>  sage: R.=LaurentSeriesRing(QQ)
>> sage: z=R(0)
>> sage: z.valuation()
>> +Infinity
>> sage: z.degree()
>> -1
>>
>> but if it's not documented, perhaps we can just ignore it.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/6a9a6131-8c51-4760-9fad-897e220bfd1fn%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/CAD0p0K4_PhM3U_gj6siv_gBH-oBefwV%2Bq7f9y0Zie27i_y%2B2iA%40mail.gmail.com.

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

[Travis Scrimshaw]

Some quick data points:

- The general graded modules (and hence algebras) code raises an error for 
`0` since it is defined there by the direct summand the element belongs to 
(and `0` belongs to all of them.
- For polynomials, it is very useful to have a single check `f.degree() > 
k` for some `k`. Having error messages or check `f.is_zero()` first makes 
things more complicated.
- Comparisons of integers to `-infinity` is (relatively) expensive. 
Although this happening frequently seems unlikely.

Martin, note that Dima is calling degree with a min/max qualifier added in 
front. I think this is leading to some confusion and cross-talk. However, I 
think it is better to have easily separable terms "valuation" and "degree" 
(which exist for polynomials).

Best,
Travis

On Saturday, March 2, 2024 at 3:44:55 AM UTC+9 Martin R wrote:

> I don't get it - are my previous messages invisible?
>
> 1st Message: I don't understand - `degree` doesn't make much sense for 
> Laurent series - there is no way to determine the degree of a LaurentSeries 
> and no way to determine the degree of a LazyLaurentSeries with one minor 
> exception - which is when it is known that the series terminates, but 
> that's rare.
>
> 2nd Message: I am very much against this.  I realise that this is a 
> convention one uses in mathematics, but here it would be extremely 
> confusing: in the lazy series code we use valuation a lot, and it must mean 
> lowest degree, but we also use the degree of polynomials and Laurent 
> polynomials and we must distinguish between the two.
>
> I feel a bit ignored,
>
> Martin
>
>
> On Friday 1 March 2024 at 19:29:26 UTC+1 Giacomo Pope wrote:
>
> As an aside, the univariate LaurentPolynomialRing had a notion of 
> `valuation` but the multivariate one didn't...
>
> In the PR: https://github.com/sagemath/sage/pull/37490 I added random 
> elements but also a notion of valuation() for the multivariate case and 
> just made it act similarly to the univariate one.
>
> On Friday, March 1, 2024 at 6:18:01 PM UTC Nils Bruin wrote:
>
> On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:
>
> Following this discussion, I have made a draft PR to change the degree for 
> *only* the LaurentPolynomialRing and I will see if the CI detects anything.
>
> https://github.com/sagemath/sage/pull/37513
>
> I agree that if we change the LaurentPolynomialRing we should also change 
> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
> method `degree()` but *does* have a `valuation()` method... so this is odd.
>
>
> OK, let's keep it that way then! I don't think there is a notion on 
> LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
> one in. I thought it existed. And I think it does:
>
>  sage: R.=LaurentSeriesRing(QQ)
> sage: z=R(0)
> sage: z.valuation()
> +Infinity
> sage: z.degree()
> -1
>
> but if it's not documented, perhaps we can just ignore it.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6a9a6131-8c51-4760-9fad-897e220bfd1fn%40googlegroups.com.

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

['Martin R' via sage-devel]

I don't get it - are my previous messages invisible?

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

2nd Message: I am very much against this.  I realise that this is a 
convention one uses in mathematics, but here it would be extremely 
confusing: in the lazy series code we use valuation a lot, and it must mean 
lowest degree, but we also use the degree of polynomials and Laurent 
polynomials and we must distinguish between the two.

I feel a bit ignored,

Martin


On Friday 1 March 2024 at 19:29:26 UTC+1 Giacomo Pope wrote:

As an aside, the univariate LaurentPolynomialRing had a notion of 
`valuation` but the multivariate one didn't...

In the PR: https://github.com/sagemath/sage/pull/37490 I added random 
elements but also a notion of valuation() for the multivariate case and 
just made it act similarly to the univariate one.

On Friday, March 1, 2024 at 6:18:01 PM UTC Nils Bruin wrote:

On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:

Following this discussion, I have made a draft PR to change the degree for 
*only* the LaurentPolynomialRing and I will see if the CI detects anything.

https://github.com/sagemath/sage/pull/37513

I agree that if we change the LaurentPolynomialRing we should also change 
the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
method `degree()` but *does* have a `valuation()` method... so this is odd.


OK, let's keep it that way then! I don't think there is a notion on 
LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
one in. I thought it existed. And I think it does:

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

but if it's not documented, perhaps we can just ignore it.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f4847819-0c18-4627-8180-bed7f69ca93cn%40googlegroups.com.

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

[Giacomo Pope]

As an aside, the univariate LaurentPolynomialRing had a notion of 
`valuation` but the multivariate one didn't...

In the PR: https://github.com/sagemath/sage/pull/37490 I added random 
elements but also a notion of valuation() for the multivariate case and 
just made it act similarly to the univariate one.

On Friday, March 1, 2024 at 6:18:01 PM UTC Nils Bruin wrote:

> On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:
>
> Following this discussion, I have made a draft PR to change the degree for 
> *only* the LaurentPolynomialRing and I will see if the CI detects anything.
>
> https://github.com/sagemath/sage/pull/37513
>
> I agree that if we change the LaurentPolynomialRing we should also change 
> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
> method `degree()` but *does* have a `valuation()` method... so this is odd.
>
>
> OK, let's keep it that way then! I don't think there is a notion on 
> LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
> one in. I thought it existed. And I think it does:
>
>  sage: R.=LaurentSeriesRing(QQ)
> sage: z=R(0)
> sage: z.valuation()
> +Infinity
> sage: z.degree()
> -1
>
> but if it's not documented, perhaps we can just ignore it.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a1a59d64-4f6a-46da-9ee4-5a414d612918n%40googlegroups.com.

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

[Nils Bruin]

On Friday 1 March 2024 at 09:49:15 UTC-8 Giacomo Pope wrote:

Following this discussion, I have made a draft PR to change the degree for 
*only* the LaurentPolynomialRing and I will see if the CI detects anything.

https://github.com/sagemath/sage/pull/37513

I agree that if we change the LaurentPolynomialRing we should also change 
the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
method `degree()` but *does* have a `valuation()` method... so this is odd.


OK, let's keep it that way then! I don't think there is a notion on 
LaurentSeriesRing that deserves the name "degree". Sorry about mixing that 
one in. I thought it existed. And I think it does:

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

but if it's not documented, perhaps we can just ignore it.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8b712294-c7bd-451d-ab77-1771d48b820an%40googlegroups.com.

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

[John H Palmieri]

There are suggestions along maybe similar lines at 
https://github.com/sagemath/sage/pull/36844, and I am trying to think of 
how we might incorporate your suggestions and the other ones. I've had the 
thought before about other documents (like our department's by-laws) that 
there should be two separate documents: the main one and then, separately, 
commentary (like the Talmud). These suggestions currently feel more like 
commentary to me, but one option would be to add a "commentary" section to 
the code of conduct.

-- 
John

On Friday, March 1, 2024 at 9:41:31 AM UTC-8 Martin R wrote:

> Thank you for the thoughtful reply!  You gave me a lot to think about, and 
> I'll do so over the weekend, rather than rushing.
>
> Best,
>
> Martin
> On Friday 1 March 2024 at 18:21:59 UTC+1 David Roe wrote:
>
>> Thank you for starting the conversation Martin.  I certainly think that 
>> all of these suggestions are appropriate to discuss, and that sage-devel is 
>> probably a better venue for discussion like this than the PR.
>>
>> On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> I would like to ask whether we might want to add some of the following 
>>> to the code of conduct, I could not find it covered there.
>>>
>>> I admit that it is unclear to me whether the discussion should be on 
>>> pull requests only.  I don't want to add the following to John's pull 
>>> request, because it definitely doesn't belong there.  Opening another one 
>>> makes things even harder to follow, so I'm trying to be brave.
>>>
>>> I imagine that the issues below may be cultural things, so I would 
>>> perfectly understand that all or some of it is perfectly OK in some 
>>> communities, and therefore should not be part of the sage code of conduct.
>>>
>>> I also admit that some of the issues below are attitudes that make it 
>>> hard for me to work on sage.  There were some situations in which I would 
>>> possibly have stopped contributing to sage, if sage wasn't a professional 
>>> necessity for me.
>>>
>>
>> I'm sorry to hear that there were situations like this.  If you think it 
>> would be helpful to describe them in more detail privately (even if you're 
>> not seeking any kind of action), feel free to write to the Code of Conduct 
>> committee.
>>  
>> Here are my thoughts on your suggestions.  I think that some of them 
>> should definitely be included, though it's not completely clear to me where 
>> (it feels awkward to add yet another enumerated list).
>>  
>>
>>> 0. sage is a community effort, and not the project of a single or even a 
>>> few persons.  Try to not identify yourself with the code in sage.
>>>
>>  
>> The community aspect of Sage is currently discussed in the introduction, 
>> and perhaps we can tweak that to incorporate this suggestion.  As for the 
>> second half, I don't understand how it fits into a code of conduct, since 
>> it seems aimed at internal processes (like how to cope if your code is 
>> removed from Sage), rather than behavior.
>>
>> Currently our introduction is "The Sage community is comprised of an 
>> international mixture of mathematicians, computer scientists, engineers, 
>> researchers, teachers, amateurs, and others with varied backgrounds. This 
>> diversity is one of our strengths, but it can also lead to communication 
>> problems and unhappiness. People who love working on Sage can more 
>> effectively collaborate with others if they follow this code."  What do you 
>> feel is missing from this that you're trying to include?
>>  
>>
>>> 1. It is not OK to judge somebody else's attempts to improve sage other 
>>> than critisising it technically or casting a negative vote.  By contrast, 
>>> emphasising the positive aspects and appreciating the effort is welcome.
>>>
>>
>> I like the idea of including more about positivity, and this fits in with 
>> Guideline 2: "Be welcoming. We strive to be a community that welcomes and 
>> supports people of all backgrounds and identities."  Maybe we can append a 
>> sentence here like "When discussing contributions, endeavor to encourage 
>> positive aspects and avoid overly harsh criticism."
>>
>> I do think there are cultural differences here, and personally I think 
>> restricting negative feedback to just voting and "technical" criticism goes 
>> too far, partly because I don't think technical is very clearly defined.  
>> There are judgement calls to be made about what should be included into 
>> Sage, which are not always a matter of what method is technically 
>> superior.  I don't think we want to restrict developer's ability to offer 
>> negative feedback, but instead to encourage people to be positive and 
>> welcoming.  I'd like to hear other perspectives on this.
>>  
>>
>>> 2. It is not OK to emphasise oneselves contributions or stressing that 
>>> one has been right.  By contrast, it is fine to express that one is happy 
>>> or perhaps even proud to have solved a particular 

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

['Martin R' via sage-devel]

On Friday 1 March 2024 at 19:03:35 UTC+1 Dima Pasechnik wrote:

On Fri, Mar 1, 2024 at 5:58 PM 'Martin R' via sage-devel <
sage-...@googlegroups.com> wrote:

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


with series (power series, or formal Laurent series) the degree is 
naturally the minimal degree,
not the maximal one. (for a non-0 series; ought to be -oo for 0).


I am very much against this.  I realise that this is a convention one uses 
in mathematics, but here it would be extremely confusing: in the lazy 
series code we use valuation a lot, and it must mean lowest degree, but we 
also use the degree of polynomials and Laurent polynomials and we must 
distinguish between the two.

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c4880989-7e66-4d18-8524-437d6c408825n%40googlegroups.com.

Re: [sage-devel] Permissions on github

[Matthias Koeppe]

On Friday, March 1, 2024 at 9:27:30 AM UTC-8 David Roe wrote:

you need some kind of admin privileges in order to add people to Triage


More specifically, it is the Maintainer role that is needed for this.

I have started to enumerate a number of duties that require the Maintainer 
role in https://github.com/sagemath/sage/wiki/NumFOCUS#project-governance



 

-- 
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/fb93df49-5fc1-45cc-be79-425a10a27650n%40googlegroups.com.

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

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 5:58 PM 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:

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

with series (power series, or formal Laurent series) the degree is
naturally the minimal degree,
not the maximal one. (for a non-0 series; ought to be -oo for 0).




> On Friday 1 March 2024 at 18:49:15 UTC+1 Giacomo Pope wrote:
>
>> Following this discussion, I have made a draft PR to change the degree
>> for *only* the LaurentPolynomialRing and I will see if the CI detects
>> anything.
>>
>> https://github.com/sagemath/sage/pull/37513
>>
>> I agree that if we change the LaurentPolynomialRing we should also change
>> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no
>> method `degree()` but *does* have a `valuation()` method... so this is odd.
>>
>> On Friday, March 1, 2024 at 5:29:53 PM UTC Martin R wrote:
>>
>>> Could you expand on 'the whole valuation interpretation of "degree" goes
>>> out of the window'?  What do you mean with "valuation interpretation"?
>>>
>>> Is raising an exception out of the question?
>>>
>>> On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote:
>>>
 On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:


 It seems that exactly the same algorithm will work (I didn't check
 this!) for Laurent polynomials (they still form a Euclidean domain), and
 there you better set degree(0)=-oo, otherwise it's going to be a problem.

 I think it's been established
 that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic.
 With the definition that (1/x).degree() == -1 it clearly is.

 I think the question is more: do we have enough evidence that setting
 degree(0) == -oo for *all* polynomial rings is significantly better (if
 better at all) that it's worth the pain and incompatibilities that would
 ensue from changing the rest of sage as well? That's not so clear to me.
 From the perspective of multivariate polynomials, the whole valuation
 interpretation of "degree" goes out of the window, so there "-1" is largely
 available and quite possibly used extensively by the underlying libraries.

 I guess one could see what happens if the change is made to Laurent
 polynomials (and Laurent series as well, perhaps?). Based on how that goes
 one could re-evaluate degrees of 0 polynomials in other polynomial rings.

 Alternatively, we could deprecate degree on them in favour of using
 valuation-inspired terms instead, where the extension val(0)=oo is more
 universal. As Oscar's example in Matlab shows, the concept of degree gets
 (mis)used for other, more implementation-oriented definitions as well, so
 perhaps the term should just be avoided for Laurent polynomials.

>>> --
> 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/b6ede155-fb29-4607-be7b-b028ce39e973n%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/CAAWYfq3O5t0X6Arwt-A2%3D464xXMQsX87zm7a%3DE8JEf55ac5e0Q%40mail.gmail.com.

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

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 5:11 PM Nils Bruin  wrote:

> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>
>
> It seems that exactly the same algorithm will work (I didn't check this!)
> for Laurent polynomials (they still form a Euclidean domain), and there you
> better set degree(0)=-oo, otherwise it's going to be a problem.
>
> I think it's been established
> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic.
> With the definition that (1/x).degree() == -1 it clearly is.
>
> I think the question is more: do we have enough evidence that setting
> degree(0) == -oo for *all* polynomial rings is significantly better (if
> better at all) that it's worth the pain and incompatibilities that would
> ensue from changing the rest of sage as well? That's not so clear to me.
> From the perspective of multivariate polynomials, the whole valuation
> interpretation of "degree" goes out of the window, so there "-1" is largely
> available and quite possibly used extensively by the underlying libraries.
>

IMHO deg(0)=-1 was chosen by Singular long time ago for purely practical
programming reasons: in C++ one has to jump  through too many hoops in
order to add +oo/-oo to Z, as a type (and it was much harder still in
old-style C++ than it is now). (probably similarly for sympy).

As I mentioned, both Macaulay2 and GAP have convertion deg(0)=-oo.

For multivariate Laurent series total degree, indeed, makes little sense,
one has to talk about vectors of degrees. Perhaps for an n-variate Laurent
series one should choose deg(0)=(-oo,-oo,...,-oo).

Dima




>
> I guess one could see what happens if the change is made to Laurent
> polynomials (and Laurent series as well, perhaps?). Based on how that goes
> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>
> Alternatively, we could deprecate degree on them in favour of using
> valuation-inspired terms instead, where the extension val(0)=oo is more
> universal. As Oscar's example in Matlab shows, the concept of degree gets
> (mis)used for other, more implementation-oriented definitions as well, so
> perhaps the term should just be avoided for Laurent polynomials.
>
> --
> 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/60c42d22-28dc-4221-96a0-b174585c9c23n%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/CAAWYfq0MdLQeTd6Gym_JNCquOm7YCLheLMyxPxn1LTF4mARLXQ%40mail.gmail.com.

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

['Martin R' via sage-devel]

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

On Friday 1 March 2024 at 18:49:15 UTC+1 Giacomo Pope wrote:

> Following this discussion, I have made a draft PR to change the degree for 
> *only* the LaurentPolynomialRing and I will see if the CI detects anything.
>
> https://github.com/sagemath/sage/pull/37513
>
> I agree that if we change the LaurentPolynomialRing we should also change 
> the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
> method `degree()` but *does* have a `valuation()` method... so this is odd.
>
> On Friday, March 1, 2024 at 5:29:53 PM UTC Martin R wrote:
>
>> Could you expand on 'the whole valuation interpretation of "degree" goes 
>> out of the window'?  What do you mean with "valuation interpretation"?
>>
>> Is raising an exception out of the question?
>>
>> On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote:
>>
>>> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>>>  
>>>
>>> It seems that exactly the same algorithm will work (I didn't check 
>>> this!) for Laurent polynomials (they still form a Euclidean domain), and 
>>> there you better set degree(0)=-oo, otherwise it's going to be a problem.
>>>
>>> I think it's been established 
>>> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic. 
>>> With the definition that (1/x).degree() == -1 it clearly is.
>>>
>>> I think the question is more: do we have enough evidence that setting 
>>> degree(0) == -oo for *all* polynomial rings is significantly better (if 
>>> better at all) that it's worth the pain and incompatibilities that would 
>>> ensue from changing the rest of sage as well? That's not so clear to me. 
>>> From the perspective of multivariate polynomials, the whole valuation 
>>> interpretation of "degree" goes out of the window, so there "-1" is largely 
>>> available and quite possibly used extensively by the underlying libraries.
>>>
>>> I guess one could see what happens if the change is made to Laurent 
>>> polynomials (and Laurent series as well, perhaps?). Based on how that goes 
>>> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>>>
>>> Alternatively, we could deprecate degree on them in favour of using 
>>> valuation-inspired terms instead, where the extension val(0)=oo is more 
>>> universal. As Oscar's example in Matlab shows, the concept of degree gets 
>>> (mis)used for other, more implementation-oriented definitions as well, so 
>>> perhaps the term should just be avoided for Laurent polynomials.
>>>
>>

-- 
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/b6ede155-fb29-4607-be7b-b028ce39e973n%40googlegroups.com.

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

[Giacomo Pope]

Following this discussion, I have made a draft PR to change the degree for 
*only* the LaurentPolynomialRing and I will see if the CI detects anything.

https://github.com/sagemath/sage/pull/37513

I agree that if we change the LaurentPolynomialRing we should also change 
the `LaurentSeriesRing`, at the moment `LazyLaurentSeriesRing` has no 
method `degree()` but *does* have a `valuation()` method... so this is odd.

On Friday, March 1, 2024 at 5:29:53 PM UTC Martin R wrote:

> Could you expand on 'the whole valuation interpretation of "degree" goes 
> out of the window'?  What do you mean with "valuation interpretation"?
>
> Is raising an exception out of the question?
>
> On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote:
>
>> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>>  
>>
>> It seems that exactly the same algorithm will work (I didn't check this!) 
>> for Laurent polynomials (they still form a Euclidean domain), and there you 
>> better set degree(0)=-oo, otherwise it's going to be a problem.
>>
>> I think it's been established 
>> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic. 
>> With the definition that (1/x).degree() == -1 it clearly is.
>>
>> I think the question is more: do we have enough evidence that setting 
>> degree(0) == -oo for *all* polynomial rings is significantly better (if 
>> better at all) that it's worth the pain and incompatibilities that would 
>> ensue from changing the rest of sage as well? That's not so clear to me. 
>> From the perspective of multivariate polynomials, the whole valuation 
>> interpretation of "degree" goes out of the window, so there "-1" is largely 
>> available and quite possibly used extensively by the underlying libraries.
>>
>> I guess one could see what happens if the change is made to Laurent 
>> polynomials (and Laurent series as well, perhaps?). Based on how that goes 
>> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>>
>> Alternatively, we could deprecate degree on them in favour of using 
>> valuation-inspired terms instead, where the extension val(0)=oo is more 
>> universal. As Oscar's example in Matlab shows, the concept of degree gets 
>> (mis)used for other, more implementation-oriented definitions as well, so 
>> perhaps the term should just be avoided for Laurent polynomials.
>>
>

-- 
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/6a79e795-60d5-4385-b2fb-79e53be18bc1n%40googlegroups.com.

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

['Martin R' via sage-devel]

Thank you for the thoughtful reply!  You gave me a lot to think about, and 
I'll do so over the weekend, rather than rushing.

Best,

Martin
On Friday 1 March 2024 at 18:21:59 UTC+1 David Roe wrote:

> Thank you for starting the conversation Martin.  I certainly think that 
> all of these suggestions are appropriate to discuss, and that sage-devel is 
> probably a better venue for discussion like this than the PR.
>
> On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> I would like to ask whether we might want to add some of the following to 
>> the code of conduct, I could not find it covered there.
>>
>> I admit that it is unclear to me whether the discussion should be on pull 
>> requests only.  I don't want to add the following to John's pull request, 
>> because it definitely doesn't belong there.  Opening another one makes 
>> things even harder to follow, so I'm trying to be brave.
>>
>> I imagine that the issues below may be cultural things, so I would 
>> perfectly understand that all or some of it is perfectly OK in some 
>> communities, and therefore should not be part of the sage code of conduct.
>>
>> I also admit that some of the issues below are attitudes that make it 
>> hard for me to work on sage.  There were some situations in which I would 
>> possibly have stopped contributing to sage, if sage wasn't a professional 
>> necessity for me.
>>
>
> I'm sorry to hear that there were situations like this.  If you think it 
> would be helpful to describe them in more detail privately (even if you're 
> not seeking any kind of action), feel free to write to the Code of Conduct 
> committee.
>  
> Here are my thoughts on your suggestions.  I think that some of them 
> should definitely be included, though it's not completely clear to me where 
> (it feels awkward to add yet another enumerated list).
>  
>
>> 0. sage is a community effort, and not the project of a single or even a 
>> few persons.  Try to not identify yourself with the code in sage.
>>
>  
> The community aspect of Sage is currently discussed in the introduction, 
> and perhaps we can tweak that to incorporate this suggestion.  As for the 
> second half, I don't understand how it fits into a code of conduct, since 
> it seems aimed at internal processes (like how to cope if your code is 
> removed from Sage), rather than behavior.
>
> Currently our introduction is "The Sage community is comprised of an 
> international mixture of mathematicians, computer scientists, engineers, 
> researchers, teachers, amateurs, and others with varied backgrounds. This 
> diversity is one of our strengths, but it can also lead to communication 
> problems and unhappiness. People who love working on Sage can more 
> effectively collaborate with others if they follow this code."  What do you 
> feel is missing from this that you're trying to include?
>  
>
>> 1. It is not OK to judge somebody else's attempts to improve sage other 
>> than critisising it technically or casting a negative vote.  By contrast, 
>> emphasising the positive aspects and appreciating the effort is welcome.
>>
>
> I like the idea of including more about positivity, and this fits in with 
> Guideline 2: "Be welcoming. We strive to be a community that welcomes and 
> supports people of all backgrounds and identities."  Maybe we can append a 
> sentence here like "When discussing contributions, endeavor to encourage 
> positive aspects and avoid overly harsh criticism."
>
> I do think there are cultural differences here, and personally I think 
> restricting negative feedback to just voting and "technical" criticism goes 
> too far, partly because I don't think technical is very clearly defined.  
> There are judgement calls to be made about what should be included into 
> Sage, which are not always a matter of what method is technically 
> superior.  I don't think we want to restrict developer's ability to offer 
> negative feedback, but instead to encourage people to be positive and 
> welcoming.  I'd like to hear other perspectives on this.
>  
>
>> 2. It is not OK to emphasise oneselves contributions or stressing that 
>> one has been right.  By contrast, it is fine to express that one is happy 
>> or perhaps even proud to have solved a particular technical problem.
>>
>
> I'm struggling to translate this idea into something concrete that I feel 
> comfortable adding to the code of conduct.  I think it's important to allow 
> people to get credit for the contributions that they've made to Sage, so I 
> don't know what part of emphasizing your own contributions is problematic.  
> Similarly, I think it's too much to ask people to not claim that they are 
> on the correct side of an argument if a discussion gets contentious.  Is 
> there some other aspect of this kind of behavior that we might focus on?
>  
>
>> 3. It is not OK to modify the description of a pull request or issue of 
>> somebody else without explicit 

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

['Martin R' via sage-devel]

Could you expand on 'the whole valuation interpretation of "degree" goes 
out of the window'?  What do you mean with "valuation interpretation"?

Is raising an exception out of the question?

On Friday 1 March 2024 at 18:11:40 UTC+1 Nils Bruin wrote:

> On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
>  
>
> It seems that exactly the same algorithm will work (I didn't check this!) 
> for Laurent polynomials (they still form a Euclidean domain), and there you 
> better set degree(0)=-oo, otherwise it's going to be a problem.
>
> I think it's been established 
> that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic. 
> With the definition that (1/x).degree() == -1 it clearly is.
>
> I think the question is more: do we have enough evidence that setting 
> degree(0) == -oo for *all* polynomial rings is significantly better (if 
> better at all) that it's worth the pain and incompatibilities that would 
> ensue from changing the rest of sage as well? That's not so clear to me. 
> From the perspective of multivariate polynomials, the whole valuation 
> interpretation of "degree" goes out of the window, so there "-1" is largely 
> available and quite possibly used extensively by the underlying libraries.
>
> I guess one could see what happens if the change is made to Laurent 
> polynomials (and Laurent series as well, perhaps?). Based on how that goes 
> one could re-evaluate degrees of 0 polynomials in other polynomial rings.
>
> Alternatively, we could deprecate degree on them in favour of using 
> valuation-inspired terms instead, where the extension val(0)=oo is more 
> universal. As Oscar's example in Matlab shows, the concept of degree gets 
> (mis)used for other, more implementation-oriented definitions as well, so 
> perhaps the term should just be avoided for Laurent polynomials.
>

-- 
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/91f07351-c3f5-4bf1-91f8-50e767075868n%40googlegroups.com.

Re: [sage-devel] Permissions on github

[David Roe]

As far as I can tell, you need some kind of admin privileges in order to
add people to Triage (which is unfortunate, since membership in this team
is critical for our reviewing process).  The method that I use is to go here
 and click on the big green
"Add member" button at the top right.  If you don't see this button, then
I'm correct about the required permissions

In the short term, I've added nadialafreniere to triage, and I'm happy to
add others by request from Sage developers that I recognize (feel free to
either email me at roed.m...@gmail.com or contact me on Zulip
).  In the long term, we should figure out a
better process and document it.
David

On Fri, Mar 1, 2024 at 11:53 AM 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:

> I couldn't find the appropriate place to ask (and I think that this should
> be fixed): how can I give someone the permission to modify labels, I think
> that's called triage team now? User name would be nadialafreniere.
>
> Thank you,
>
> Martin
>
> --
> You received this message because you are subscribed 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/635a7d01-c8fe-4619-8684-2ce6de55355cn%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/CAChs6_%3DAZBzhqqT_KfzgBo0PMzktgF30MDWn0bwcHEoqpBHneg%40mail.gmail.com.

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

[David Roe]

Thank you for starting the conversation Martin.  I certainly think that all
of these suggestions are appropriate to discuss, and that sage-devel is
probably a better venue for discussion like this than the PR.

On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:

> I would like to ask whether we might want to add some of the following to
> the code of conduct, I could not find it covered there.
>
> I admit that it is unclear to me whether the discussion should be on pull
> requests only.  I don't want to add the following to John's pull request,
> because it definitely doesn't belong there.  Opening another one makes
> things even harder to follow, so I'm trying to be brave.
>
> I imagine that the issues below may be cultural things, so I would
> perfectly understand that all or some of it is perfectly OK in some
> communities, and therefore should not be part of the sage code of conduct.
>
> I also admit that some of the issues below are attitudes that make it hard
> for me to work on sage.  There were some situations in which I would
> possibly have stopped contributing to sage, if sage wasn't a professional
> necessity for me.
>

I'm sorry to hear that there were situations like this.  If you think it
would be helpful to describe them in more detail privately (even if you're
not seeking any kind of action), feel free to write to the Code of Conduct
committee.

Here are my thoughts on your suggestions.  I think that some of them should
definitely be included, though it's not completely clear to me where (it
feels awkward to add yet another enumerated list).


> 0. sage is a community effort, and not the project of a single or even a
> few persons.  Try to not identify yourself with the code in sage.
>

The community aspect of Sage is currently discussed in the introduction,
and perhaps we can tweak that to incorporate this suggestion.  As for the
second half, I don't understand how it fits into a code of conduct, since
it seems aimed at internal processes (like how to cope if your code is
removed from Sage), rather than behavior.

Currently our introduction is "The Sage community is comprised of an
international mixture of mathematicians, computer scientists, engineers,
researchers, teachers, amateurs, and others with varied backgrounds. This
diversity is one of our strengths, but it can also lead to communication
problems and unhappiness. People who love working on Sage can more
effectively collaborate with others if they follow this code."  What do you
feel is missing from this that you're trying to include?


> 1. It is not OK to judge somebody else's attempts to improve sage other
> than critisising it technically or casting a negative vote.  By contrast,
> emphasising the positive aspects and appreciating the effort is welcome.
>

I like the idea of including more about positivity, and this fits in with
Guideline 2: "Be welcoming. We strive to be a community that welcomes and
supports people of all backgrounds and identities."  Maybe we can append a
sentence here like "When discussing contributions, endeavor to encourage
positive aspects and avoid overly harsh criticism."

I do think there are cultural differences here, and personally I think
restricting negative feedback to just voting and "technical" criticism goes
too far, partly because I don't think technical is very clearly defined.
There are judgement calls to be made about what should be included into
Sage, which are not always a matter of what method is technically
superior.  I don't think we want to restrict developer's ability to offer
negative feedback, but instead to encourage people to be positive and
welcoming.  I'd like to hear other perspectives on this.


> 2. It is not OK to emphasise oneselves contributions or stressing that one
> has been right.  By contrast, it is fine to express that one is happy or
> perhaps even proud to have solved a particular technical problem.
>

I'm struggling to translate this idea into something concrete that I feel
comfortable adding to the code of conduct.  I think it's important to allow
people to get credit for the contributions that they've made to Sage, so I
don't know what part of emphasizing your own contributions is problematic.
Similarly, I think it's too much to ask people to not claim that they are
on the correct side of an argument if a discussion gets contentious.  Is
there some other aspect of this kind of behavior that we might focus on?


> 3. It is not OK to modify the description of a pull request or issue of
> somebody else without explicit permission, ideally on the ticket so that
> the permission is visible to all readers.
>

I actually think that modifying someone else's pull request to clarify it,
fix typos, or adjust it once the scope has changed is fine.  I'm curious
what other people think, and what our community standard should be.
Martin, what aspects of this bother you?  Are there any kinds of
modifications that you think are 

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

[Nils Bruin]

On Friday 1 March 2024 at 04:26:43 UTC-8 Dima Pasechnik wrote:
 

It seems that exactly the same algorithm will work (I didn't check this!) 
for Laurent polynomials (they still form a Euclidean domain), and there you 
better set degree(0)=-oo, otherwise it's going to be a problem.

I think it's been established 
that LaurentPolynomialRing(QQ,'x').zero().degree() == -1 is problematic. 
With the definition that (1/x).degree() == -1 it clearly is.

I think the question is more: do we have enough evidence that setting 
degree(0) == -oo for *all* polynomial rings is significantly better (if 
better at all) that it's worth the pain and incompatibilities that would 
ensue from changing the rest of sage as well? That's not so clear to me. 
>From the perspective of multivariate polynomials, the whole valuation 
interpretation of "degree" goes out of the window, so there "-1" is largely 
available and quite possibly used extensively by the underlying libraries.

I guess one could see what happens if the change is made to Laurent 
polynomials (and Laurent series as well, perhaps?). Based on how that goes 
one could re-evaluate degrees of 0 polynomials in other polynomial rings.

Alternatively, we could deprecate degree on them in favour of using 
valuation-inspired terms instead, where the extension val(0)=oo is more 
universal. As Oscar's example in Matlab shows, the concept of degree gets 
(mis)used for other, more implementation-oriented definitions as well, so 
perhaps the term should just be avoided for Laurent polynomials.

-- 
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/60c42d22-28dc-4221-96a0-b174585c9c23n%40googlegroups.com.

[sage-devel] Permissions on github

['Martin R' via sage-devel]

I couldn't find the appropriate place to ask (and I think that this should 
be fixed): how can I give someone the permission to modify labels, I think 
that's called triage team now? User name would be nadialafreniere.

Thank you,

Martin

-- 
You received this message because you are subscribed 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/635a7d01-c8fe-4619-8684-2ce6de55355cn%40googlegroups.com.

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

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 11:41 AM Oscar Benjamin 
wrote:

> On Fri, 1 Mar 2024 at 11:15, John Cremona  wrote:
> >
> > On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik  wrote:
> >>
> >> On Fri, Mar 1, 2024 at 10:24 AM John Cremona 
> wrote:
> >>>
> >>> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:
> 
> 
> 
>  On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
> sage-devel@googlegroups.com> wrote:
>  >I'd be OK with raising an exception or with -oo, but it should be
> uniform,
>  >and I think it should be the same for polynomials, Laurent
> polynomials and
>  >in the same spirit for degree and valuation.
>  >
>  >It might be best to raise an exception, because this ensures that
> the zero
>  >polynomial gets special treatment.
> 
>  Exceptions are expensive, performance-wise, and using them as a
> regular means of controlling the flow of the algorithm execution is not a
> good idea.
>  A simple  if/then/else  is much cheaper.
> >>>
> >>>
> >>> Isn't this suggestion to have f.degree() raise an exception when f is
> zero, but also then that any code which needs the degree to treat 0 as a
> special case (where that makes sense)?   To it would be the caller's
> responsibility to do that with a test of f.is_zero() or whatever, rather
> than by seeing if an exception is triggered.
> >>
> >>
> >> Letting degree(0) throw an exception means that every place where you
> want to test whether the degree of fg satisfies something needs a testing
> whether f or g is 0, in order to avoid an exception.
> >
> >
> > Fair enough.  I had been assuming that for the types we are talking
> about testing for equality with 0 would be fast, but perhaps it is not.
>
> If p.degree() can do this quickly then there is no reason that some
> other function couldn't be made to return the equivalent of p.degree()
> < 0 quickly. It would sometimes be a bit awkward though for deg(0) to
> raise an exception. I see examples of code in sympy where e.g. the
> degrees of polynomials are reduced in a loop and having deg(0) < 0
> naturally captures the the control flow that is needed.
>
> >> OTOH, setting the degree of 0 to be -oo has an obvious advantage: it
> automaticlly gives mathematically correct degree of fg, by using
> degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking
> the degree is (or at least ought to be) faster than comparing for equality
> to 0.
>
> Do you see examples where arithmetic with degree(0) is used in practice?
>
> When I looked for these in the sympy code I didn't find any even
> though the -oo convention was used. I just don't think it comes up in
> real code.
>

a natural way to program long division of univariate polynomial n by
univariate polynomial d,
to get n=dq+r can folllow Wikipedia's
https://en.wikipedia.org/wiki/Polynomial_long_division#Pseudocode

There they have the condion

*while* r ≠ 0 *and* degree(r) ≥ degree(d) *do*


which with the convention degree(0)=-oo can be simplified to

*while* degree(r) ≥ degree(d) *do*


here of course any negative degree(0) will work, e.g. -1, not only -oo.

It seems that exactly the same algorithm will work (I didn't check this!)
for Laurent polynomials (they still form a Euclidean domain), and there you
better set degree(0)=-oo, otherwise it's going to be a problem.

Dima


> > It's a little dangerous to talk of -oo being "mathematically correct",
> but I have given this definition myself in undergraduate course (and for
> the reason you give) so that's ok, especially as in Sage we do have -oo as
> a possible return value and no requiremt for the value to always be of the
> same type (e.g. Integer).
>
> There might not be any "requirement" for degree() to return objects of
> the same type but from a computational perspective it is generally
> better to use well defined types. Python allows mixing types up but
> that doesn't make it a good idea to do so especially in performance
> sensitive code.
>
> --
> Oscar
>
> --
> 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/CAHVvXxRDh1y6h3PiRZNAzT50DJAfgLGMxzhdMVrV1SiNWHO24w%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/CAAWYfq31X6RUxzA0meovV%2Bq5toxCPGJqKb5DX9zRBizvA%3DoyaA%40mail.gmail.com.

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

[Oscar Benjamin]

On Fri, 1 Mar 2024 at 11:51, 'Martin R' via sage-devel
 wrote:
> On Friday 1 March 2024 at 12:15:36 UTC+1 John Cremona wrote:
> On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik  wrote:
>
> OTOH, setting the degree of 0 to be -oo has an obvious advantage: it 
> automaticlly gives mathematically correct degree of fg, by using 
> degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking 
> the degree is (or at least ought to be) faster than comparing for equality to 
> 0.
>
> It's a little dangerous to talk of -oo being "mathematically correct", but I 
> have given this definition myself in undergraduate course (and for the reason 
> you give) so that's ok, especially as in Sage we do have -oo as a possible 
> return value and no requiremt for the value to always be of the same type 
> (e.g. Integer).
>
> I would rather say that "-1" is in some cases "mathematically incorrect", in 
> particular for Laurent polynomials :-)

What exactly is the "mathematically correct" meaning of "degree" for
Laurent polynomials?

I haven't seen other examples where this is defined except Matlab
which defines it differently from Sage:

https://uk.mathworks.com/help/wavelet/ref/laurentpolynomial.degree.html

The Matlab definition is basically that deg(p(x)*x^m) = deg(p(x)).
This means that for nonzero Laurent polynomials the degree is always
nonnegative. Here deg(x^m) = 0 i.e. the degree of a unit is always 0.

I haven't thought much about this but this definition of degree seems
consistent with the notion of degree as a Euclidean function that can
define Euclidean division. In the sympy polynomial code all uses of
degree are in the polynomial division, gcd and factor code because the
main use of degree is in defining division.

Oscar

-- 
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/CAHVvXxQErjrcvnCKk4j4c5-F%3DZDQ%3D6LpZ1OycaqEtBBx7wGfPA%40mail.gmail.com.

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

['Martin R' via sage-devel]

On Friday 1 March 2024 at 12:15:36 UTC+1 John Cremona wrote:

On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik  wrote:



On Fri, Mar 1, 2024 at 10:24 AM John Cremona  wrote:



On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:



On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
sage-...@googlegroups.com> wrote:
>I'd be OK with raising an exception or with -oo, but it should be uniform, 
>and I think it should be the same for polynomials, Laurent polynomials and 
>in the same spirit for degree and valuation.
>
>It might be best to raise an exception, because this ensures that the zero 
>polynomial gets special treatment.

Exceptions are expensive, performance-wise, and using them as a regular 
means of controlling the flow of the algorithm execution is not a good idea.
A simple  if/then/else  is much cheaper.


Isn't this suggestion to have f.degree() raise an exception when f is zero, 
but also then that any code which needs the degree to treat 0 as a special 
case (where that makes sense)?   To it would be the caller's responsibility 
to do that with a test of f.is_zero() or whatever, rather than by seeing if 
an exception is triggered.


Exactly, sorry for being unclear.  try - except would certainly be out of 
place in this case.

Letting degree(0) throw an exception means that every place where you want 
to test whether the degree of fg satisfies something needs a testing 
whether f or g is 0, in order to avoid an exception.


Yes indeed - unless you already know that the polynomial is non-zero.
 

Fair enough.  I had been assuming that for the types we are talking about 
testing for equality with 0 would be fast, but perhaps it is not.


I just found that Polynomial.is_zero checks whether degree is negative, and 
degree is `return smallInteger(len(self._coeffs) - 1)`, for flint 
polynomials it is `return smallInteger(fmpq_poly_degree(self._poly))`.  So, 
indeed, either change would come with a cost.

OTOH, setting the degree of 0 to be -oo has an obvious advantage: it 
automaticlly gives mathematically correct degree of fg, by using 
degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking 
the degree is (or at least ought to be) faster than comparing for equality 
to 0.


It's a little dangerous to talk of -oo being "mathematically correct", but 
I have given this definition myself in undergraduate course (and for the 
reason you give) so that's ok, especially as in Sage we do have -oo as a 
possible return value and no requiremt for the value to always be of the 
same type (e.g. Integer).


I would rather say that "-1" is in some cases "mathematically incorrect", 
in particular for Laurent polynomials :-)

To make it clear, I am not against -oo, I find -1 quite problematic (for 
user facing code, and because I really want uniformity for polynomials and 
Laurent polynomials and their series variants), and I think that raising an 
exception should be best performance-wise, but probably most work.

Best wishes,

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/18554706-6f6e-4946-b853-f83faa10076en%40googlegroups.com.

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

[Oscar Benjamin]

On Fri, 1 Mar 2024 at 11:15, John Cremona  wrote:
>
> On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik  wrote:
>>
>> On Fri, Mar 1, 2024 at 10:24 AM John Cremona  wrote:
>>>
>>> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:



 On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel 
  wrote:
 >I'd be OK with raising an exception or with -oo, but it should be uniform,
 >and I think it should be the same for polynomials, Laurent polynomials and
 >in the same spirit for degree and valuation.
 >
 >It might be best to raise an exception, because this ensures that the zero
 >polynomial gets special treatment.

 Exceptions are expensive, performance-wise, and using them as a regular 
 means of controlling the flow of the algorithm execution is not a good 
 idea.
 A simple  if/then/else  is much cheaper.
>>>
>>>
>>> Isn't this suggestion to have f.degree() raise an exception when f is zero, 
>>> but also then that any code which needs the degree to treat 0 as a special 
>>> case (where that makes sense)?   To it would be the caller's responsibility 
>>> to do that with a test of f.is_zero() or whatever, rather than by seeing if 
>>> an exception is triggered.
>>
>>
>> Letting degree(0) throw an exception means that every place where you want 
>> to test whether the degree of fg satisfies something needs a testing whether 
>> f or g is 0, in order to avoid an exception.
>
>
> Fair enough.  I had been assuming that for the types we are talking about 
> testing for equality with 0 would be fast, but perhaps it is not.

If p.degree() can do this quickly then there is no reason that some
other function couldn't be made to return the equivalent of p.degree()
< 0 quickly. It would sometimes be a bit awkward though for deg(0) to
raise an exception. I see examples of code in sympy where e.g. the
degrees of polynomials are reduced in a loop and having deg(0) < 0
naturally captures the the control flow that is needed.

>> OTOH, setting the degree of 0 to be -oo has an obvious advantage: it 
>> automaticlly gives mathematically correct degree of fg, by using 
>> degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking 
>> the degree is (or at least ought to be) faster than comparing for equality 
>> to 0.

Do you see examples where arithmetic with degree(0) is used in practice?

When I looked for these in the sympy code I didn't find any even
though the -oo convention was used. I just don't think it comes up in
real code.

> It's a little dangerous to talk of -oo being "mathematically correct", but I 
> have given this definition myself in undergraduate course (and for the reason 
> you give) so that's ok, especially as in Sage we do have -oo as a possible 
> return value and no requiremt for the value to always be of the same type 
> (e.g. Integer).

There might not be any "requirement" for degree() to return objects of
the same type but from a computational perspective it is generally
better to use well defined types. Python allows mixing types up but
that doesn't make it a good idea to do so especially in performance
sensitive code.

--
Oscar

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

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

[John Cremona]

On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik  wrote:

>
>
> On Fri, Mar 1, 2024 at 10:24 AM John Cremona 
> wrote:
>
>>
>>
>> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:
>>
>>>
>>>
>>> On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
>>> sage-devel@googlegroups.com> wrote:
>>> >I'd be OK with raising an exception or with -oo, but it should be
>>> uniform,
>>> >and I think it should be the same for polynomials, Laurent polynomials
>>> and
>>> >in the same spirit for degree and valuation.
>>> >
>>> >It might be best to raise an exception, because this ensures that the
>>> zero
>>> >polynomial gets special treatment.
>>>
>>> Exceptions are expensive, performance-wise, and using them as a regular
>>> means of controlling the flow of the algorithm execution is not a good idea.
>>> A simple  if/then/else  is much cheaper.
>>>
>>
>> Isn't this suggestion to have f.degree() raise an exception when f is
>> zero, but also then that any code which needs the degree to treat 0 as a
>> special case (where that makes sense)?   To it would be the caller's
>> responsibility to do that with a test of f.is_zero() or whatever, rather
>> than by seeing if an exception is triggered.
>>
>
> Letting degree(0) throw an exception means that every place where you want
> to test whether the degree of fg satisfies something needs a testing
> whether f or g is 0, in order to avoid an exception.
>

Fair enough.  I had been assuming that for the types we are talking about
testing for equality with 0 would be fast, but perhaps it is not.


>
> OTOH, setting the degree of 0 to be -oo has an obvious advantage: it
> automaticlly gives mathematically correct degree of fg, by using
> degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking
> the degree is (or at least ought to be) faster than comparing for equality
> to 0.
>

It's a little dangerous to talk of -oo being "mathematically correct", but
I have given this definition myself in undergraduate course (and for the
reason you give) so that's ok, especially as in Sage we do have -oo as a
possible return value and no requiremt for the value to always be of the
same type (e.g. Integer).


>
> Yes, it requires a change of the mental picture somehow. But same applies
> for e.g. using projective setting instead of affine one in geometry: you
> don't need to throw a mental exception as soon as you get parallel lines :-)
>
> Dima
>
>
>
>
>
>
>>
>> John
>>
>>
>>>
>>> Dima
>>> >
>>> >Martin
>>> >On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:
>>> >
>>> >> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
>>> >>
>>> >> How about using something like
>>> https://github.com/NeilGirdhar/extended_int
>>> >> ?
>>> >> (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/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.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/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%40mail.gmail.com
>> 

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

[Dima Pasechnik]

On Fri, Mar 1, 2024 at 10:24 AM John Cremona  wrote:

>
>
> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:
>
>>
>>
>> On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
>> sage-devel@googlegroups.com> wrote:
>> >I'd be OK with raising an exception or with -oo, but it should be
>> uniform,
>> >and I think it should be the same for polynomials, Laurent polynomials
>> and
>> >in the same spirit for degree and valuation.
>> >
>> >It might be best to raise an exception, because this ensures that the
>> zero
>> >polynomial gets special treatment.
>>
>> Exceptions are expensive, performance-wise, and using them as a regular
>> means of controlling the flow of the algorithm execution is not a good idea.
>> A simple  if/then/else  is much cheaper.
>>
>
> Isn't this suggestion to have f.degree() raise an exception when f is
> zero, but also then that any code which needs the degree to treat 0 as a
> special case (where that makes sense)?   To it would be the caller's
> responsibility to do that with a test of f.is_zero() or whatever, rather
> than by seeing if an exception is triggered.
>

Letting degree(0) throw an exception means that every place where you want
to test whether the degree of fg satisfies something needs a testing
whether f or g is 0, in order to avoid an exception.

OTOH, setting the degree of 0 to be -oo has an obvious advantage: it
automaticlly gives mathematically correct degree of fg, by using
degree(fg)=degree(f)+degree(g), regardless of f or g being 0. And checking
the degree is (or at least ought to be) faster than comparing for equality
to 0.

Yes, it requires a change of the mental picture somehow. But same applies
for e.g. using projective setting instead of affine one in geometry: you
don't need to throw a mental exception as soon as you get parallel lines :-)

Dima






>
> John
>
>
>>
>> Dima
>> >
>> >Martin
>> >On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:
>> >
>> >> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
>> >>
>> >> How about using something like
>> https://github.com/NeilGirdhar/extended_int
>> >> ?
>> >> (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/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.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/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%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/CAAWYfq0zF8ARVr_FbbKd7WAhM8t6cBSqegXZzKsSSx1Au5mFMw%40mail.gmail.com.

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

['Martin R' via sage-devel]

I would like to ask whether we might want to add some of the following to 
the code of conduct, I could not find it covered there.

I admit that it is unclear to me whether the discussion should be on pull 
requests only.  I don't want to add the following to John's pull request, 
because it definitely doesn't belong there.  Opening another one makes 
things even harder to follow, so I'm trying to be brave.

I imagine that the issues below may be cultural things, so I would 
perfectly understand that all or some of it is perfectly OK in some 
communities, and therefore should not be part of the sage code of conduct.

I also admit that some of the issues below are attitudes that make it hard 
for me to work on sage.  There were some situations in which I would 
possibly have stopped contributing to sage, if sage wasn't a professional 
necessity for me.

0. sage is a community effort, and not the project of a single or even a 
few persons.  Try to not identify yourself with the code in sage.
1. It is not OK to judge somebody else's attempts to improve sage other 
than critisising it technically or casting a negative vote.  By contrast, 
emphasising the positive aspects and appreciating the effort is welcome.
2. It is not OK to emphasise oneselves contributions or stressing that one 
has been right.  By contrast, it is fine to express that one is happy or 
perhaps even proud to have solved a particular technical problem.
3. It is not OK to modify the description of a pull request or issue of 
somebody else without explicit permission, ideally on the ticket so that 
the permission is visible to all readers.
4. It is not OK to change a pull request to "positive review" if someone 
has already expressed explicitly that it shouldn't be merged, and there 
hasn't been a vote.

Comments and variations, but also saying that this should not be discussed 
for a particular reason: welcome!

Best wishes,

Martin
On Wednesday 28 February 2024 at 22:24:29 UTC+1 John H Palmieri wrote:

> Dear colleagues,
>
> I am working on some changes to Sage's Code of Conduct, and I am asking 
> for comments. Once the draft has stabilized, then we will hold a vote on 
> sage-devel to approve (or not) the changes. Please visit 
> https://github.com/sagemath/sage/pull/37501 to see the proposal.
>
> The current Code of Conduct was approved by a vote in sage-devel almost 10 
> years ago. My intention is not to alter the core principles in the Code of 
> Conduct, but instead to add more details: for example, how should you 
> report a possible violation, what are possible consequences if the Sage 
> Code of Conduct Committee (what has until now been called the Sage Abuse 
> Committee) finds that a violation occurred, how to amend the document, etc. 
> The changes are based in large part on similar documents from SciPy and 
> NumFOCUS: we are not reinventing the wheel.
>
> As such, I hope that the proposed changes are (a) not controversial, and 
> (b) a clear improvement. I could certainly be wrong about either of these, 
> but I will make this suggestion: if you agree with me about (a) and (b) and 
> you also want to propose changes that are potentially more controversial, 
> then I would ask that you make that proposal separately so that the Sage 
> community can vote on it separately, and the changes can be merged 
> independently of each other.
>
> Please take a look and leave comments on the PR.
>
> -- 
> John
>
>

-- 
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/76cb78c4-c01d-4695-8630-95f6a6a809e7n%40googlegroups.com.

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

[John Cremona]

On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik  wrote:

>
>
> On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel <
> sage-devel@googlegroups.com> wrote:
> >I'd be OK with raising an exception or with -oo, but it should be
> uniform,
> >and I think it should be the same for polynomials, Laurent polynomials
> and
> >in the same spirit for degree and valuation.
> >
> >It might be best to raise an exception, because this ensures that the
> zero
> >polynomial gets special treatment.
>
> Exceptions are expensive, performance-wise, and using them as a regular
> means of controlling the flow of the algorithm execution is not a good idea.
> A simple  if/then/else  is much cheaper.
>

Isn't this suggestion to have f.degree() raise an exception when f is zero,
but also then that any code which needs the degree to treat 0 as a special
case (where that makes sense)?   To it would be the caller's responsibility
to do that with a test of f.is_zero() or whatever, rather than by seeing if
an exception is triggered.

John


>
> Dima
> >
> >Martin
> >On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:
> >
> >> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
> >>
> >> How about using something like
> https://github.com/NeilGirdhar/extended_int
> >> ?
> >> (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/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.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/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%40mail.gmail.com.

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

[Dima Pasechnik]

On 1 March 2024 09:07:26 GMT, 'Martin R' via sage-devel 
 wrote:
>I'd be OK with raising an exception or with -oo, but it should be uniform, 
>and I think it should be the same for polynomials, Laurent polynomials and 
>in the same spirit for degree and valuation.
>
>It might be best to raise an exception, because this ensures that the zero 
>polynomial gets special treatment.

Exceptions are expensive, performance-wise, and using them as a regular means 
of controlling the flow of the algorithm execution is not a good idea.
A simple  if/then/else  is much cheaper.

Dima
>
>Martin
>On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:
>
>> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
>>
>> How about using something like https://github.com/NeilGirdhar/extended_int 
>> ?
>> (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/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.com.

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

[Gareth Ma]

And that will be a problem when `R` is a laurent polynomial ring.

On 01/03/2024 09:12, Gareth Ma wrote:

I lean towards setting it to -∞.

While we are at this, how should `R.random_element` be called? The 
method currently takes a `degree` argument, which is a tuple of lower 
and upper bound, and if the user sets the lower bound to -1, then `0` 
is a possible outcome. Would the user call it with `degree=(-oo, 
upper_bound)` instead in the future?


Best regards,
Gareth

On 01/03/2024 09:07, 'Martin R' via sage-devel wrote:
I'd be OK with raising an exception or with -oo, but it should be 
uniform, and I think it should be the same for polynomials, Laurent 
polynomials and in the same spirit for degree and valuation.


It might be best to raise an exception, because this ensures that the 
zero polynomial gets special treatment.


Martin
On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:

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

How about using something like
https://github.com/NeilGirdhar/extended_int ?
(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/ec50bffa-37ef-4bee-9095-09e738be1842n%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/18c66bb0-b11f-48b8-9de6-403ebc5cb2d5%40gmail.com.

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

[Gareth Ma]

I lean towards setting it to -∞.

While we are at this, how should `R.random_element` be called? The 
method currently takes a `degree` argument, which is a tuple of lower 
and upper bound, and if the user sets the lower bound to -1, then `0` is 
a possible outcome. Would the user call it with `degree=(-oo, 
upper_bound)` instead in the future?


Best regards,
Gareth

On 01/03/2024 09:07, 'Martin R' via sage-devel wrote:
I'd be OK with raising an exception or with -oo, but it should be 
uniform, and I think it should be the same for polynomials, Laurent 
polynomials and in the same spirit for degree and valuation.


It might be best to raise an exception, because this ensures that the 
zero polynomial gets special treatment.


Martin
On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:

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

How about using something like
https://github.com/NeilGirdhar/extended_int ?
(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/ec50bffa-37ef-4bee-9095-09e738be1842n%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/6e66f617-3cc4-4657-a880-c3494a28decb%40gmail.com.

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

['Martin R' via sage-devel]

I'd be OK with raising an exception or with -oo, but it should be uniform, 
and I think it should be the same for polynomials, Laurent polynomials and 
in the same spirit for degree and valuation.

It might be best to raise an exception, because this ensures that the zero 
polynomial gets special treatment.

Martin
On Thursday 29 February 2024 at 22:54:20 UTC+1 Nils Bruin wrote:

> On Thursday 29 February 2024 at 11:15:21 UTC-8 Dima Pasechnik wrote:
>
> How about using something like https://github.com/NeilGirdhar/extended_int 
> ?
> (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/ec50bffa-37ef-4bee-9095-09e738be1842n%40googlegroups.com.