On Fri, 1 Mar 2024 at 11:03, Dima Pasechnik <dimp...@gmail.com> wrote:
> > > On Fri, Mar 1, 2024 at 10:24 AM John Cremona <john.crem...@gmail.com> > wrote: > >> >> >> On Fri, 1 Mar 2024 at 10:04, Dima Pasechnik <dimp...@gmail.com> 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.<x>=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.<x>=QQ[] >>> >> sage: B.<y>=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 >> <https://groups.google.com/d/msgid/sage-devel/CAD0p0K45r2ishqx4kzEwuVF9%3DYDtojjteBn3snKMkGj8ijb72g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 > <https://groups.google.com/d/msgid/sage-devel/CAAWYfq0zF8ARVr_FbbKd7WAhM8t6cBSqegXZzKsSSx1Au5mFMw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAD0p0K5TXXxwoVQ7vsxgWdcafu7LF4QVa8Yp4914%3DLswocYKVg%40mail.gmail.com.
