On Fri, Mar 1, 2024 at 11:41 AM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote:
> On Fri, 1 Mar 2024 at 11:15, John Cremona <john.crem...@gmail.com> wrote: > > > > 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. > > 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.
