On Aug 5, 2010, at 5:45 PM, Mateusz Paprocki wrote: > Hi, > > On Thu, Aug 05, 2010 at 05:09:26PM -0600, Aaron S. Meurer wrote: >> I didn't want to open an issue before asking here, because for all I know >> there could be a very good reason for this. >> >> In [1]: Poly(-5*x**3, x).div(Poly(3*x, x)) >> Out[1]: (Poly(0, x, domain='ZZ'), Poly(-5*x**3, x, domain='ZZ')) >> >> In [2]: Poly(-5*x**3, x, field=True).div(Poly(3*x, x, field=True)) >> Out[2]: (Poly(-5/3*x**2, x, domain='QQ'), Poly(0, x, domain='QQ')) >> >> I understand that it doesn't want to create field coefficients, but I >> thought that the definition of polynomial division and remainder was that >> a.div(b) returns q and r such that a == b*q + r and **either r == 0 or >> deg(r) < deg(b)**. [1] obviously does not satisfy this second condition. >> So what definition does it use? >> >> This is causing problems in the Risch algorithm. It seems like I need to be >> using field=True every time I create a Poly, or else I will get wrong >> results. But then that gives things like gcd() problems. >> >> By the way, I know about pdiv. But I think regular div() should be >> returning results with field coefficients if it must to satisfy the >> definition, unless I am seriously missing something. >> > > The conditions are met only over a field or when b is monic. Over > integers with non-monic b you arrive with the problem you showed. > If you rely on those conditions (e.g. you are creating a sequence > of polynomials with decreasing degrees) then you have to perform > computations over a field (unless your polynomials are monic --- > not a very interesting case in general). > > I guess you run into this problem somewhere around EEA (Extended > Euclidean algorithm). In this case (and a few other, e.g. Strum > sequences) user-level polynomial manipulation functions switch > ground domain to a field automatically (on lower levels you get > DomainError exception to avoid infinite loops). > > So, you will have to use field=True whenever the conditions must > be met. We may also think about adding this automatic behaviour > to div() (as it is done in gcdex(), half_gcdex(), sturm() …).
I guess I will just use field=True. Maybe there should be a field option to div. I do think that user level functions should be assuming a field ground domain by default, unless they are instructed to do otherwise. > > You said that there are problems with gcd() computations. What > is specifically wrong here? Maybe it's an issue that GCD over > a field is always monic in SymPy? Yeah that's basically the problem. splitfactor() uses gcd() to split a function into normal and special parts (like splitter() in heurisch), but it only splits apart the coefficients correctly if it takes the ring gcd. Maybe there's a better solution, but right now I have had to take the gcd with respect to each coefficient and its inverse, such as x and 1/x. I think I tried using a similar method as splitter, with the loop, but it didn't work. This was all a while ago, so I am not remembering the details the best. Maybe I need to revisit the problem. Aaron Meurer > >> Aaron Meurer >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sy...@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> > > -- > Mateusz > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
