--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c9c805f9-fbd0-4591-8729-002f3ad90fa1n%40googlegroups.com.
I don't know the history of this choice or what we should be doing generally. -1 for polynomials with only positive degree seems like a computer science workaround, but for the LaurentPolynomialRing it just seems wrong?
On Wednesday 28 February 2024 at 08:03:45 UTC-8 Giacomo Pope wrote:I don't know the history of this choice or what we should be doing generally. -1 for polynomials with only positive degree seems like a computer science workaround, but for the LaurentPolynomialRing it just seems wrong?I think it's more than just a CS workaround. It has its roots in dimension considerations: the space of polynomials of degree at most d is (d+1)-dimensional. WIth that convention, 0 having degree -1 makes perfect sense.
For deg = - ord_infty it should definitely be -oo, though, and for Laurent polynomials the dimension argument doesn't work.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/ac40d2e7-5e71-43e1-8914-869081f9bdd9n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%40mail.gmail.com.
I recently reviewed cases in the sympy polys code that handle the
degree of a zero polynomial:
https://github.com/sympy/sympy/pull/25784
My conclusion is that it is sometimes useful that deg(0) < deg(p) for
p != 0 but otherwise it is not really possible to use the value of
deg(0) for anything meaningful in practice. Generally if deg(p) is
needed then the zero polynomial needs special handling that no
particular value of deg(0) helps with. I would prefer that deg(0) = -1
just so that the deg() function has a well defined type.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRe119u%3Dy-xk1O-BvWH_f1xxnHsuQCzZm_4xYRD-_NEFw%40mail.gmail.com.
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 makea perfect sense.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@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.
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.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/D20DACD9-8D5A-48F4-81F5-141CF0181BA1%40gmail.com.
On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik <dim...@gmail.com> 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%40mail.gmail.com.
On Fri, Mar 1, 2024 at 10:24 AM John Cremona <john.c...@gmail.com> wrote:On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik <dim...@gmail.com> 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.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0zF8ARVr_FbbKd7WAhM8t6cBSqegXZzKsSSx1Au5mFMw%40mail.gmail.com.
On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik <dim...@gmail.com> wrote:On Fri, Mar 1, 2024 at 10:24 AM John Cremona <john.c...@gmail.com> wrote:On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik <dim...@gmail.com> 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.
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).
> 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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAHVvXxRDh1y6h3PiRZNAzT50DJAfgLGMxzhdMVrV1SiNWHO24w%40mail.gmail.com.
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.
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+...@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.
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.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+...@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.
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).
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.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.
--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6a9a6131-8c51-4760-9fad-897e220bfd1fn%40googlegroups.com.