On Apr 9, 7:05 pm, Ondrej Certik <ond...@certik.cz> wrote: > On Fri, Apr 9, 2010 at 1:07 PM, Ben Goodrich <goodrich....@gmail.com> wrote: > > So far, that is only using a small amount of RAM, but it is still > > calculating. I will report back when it finishes or errors. > > Yep, report back. > > Ondrej
Okay, wrapping the polynomials inside Poly() largely mitigated the RAM issue inside quo(). With about 1.5GB of RAM it can get as far as it was getting with about 5GB of RAM before. One thing that I discovered is that if both the numerator and denominator are Poly class, then the output of quo() is also Poly class. This caused an issue when the loop came back around to the top because my simplifications in basic sympy arithmetic (which were a house of cards to begin with) came out differently in Poly arithmetic. That is why I was utilizing the positivity assumptions when taking square roots. Is there a way to declare a Poly to be non-negative? I see that there are is_nonnegative() methods in the source code but I could not figure out how to set this property. If that is not possible yet, perhaps it would be a good feature to add. Instead I discovered that if the denominator in quo() is a basic sympy expression that happens to be a multivariate polynomial, then the output of quo() is a basic sympy expression again (that may be the intended behavior), so my code could work the same way as before. That is probably not optimal because the assumptions seem to be a drag on the speed and necessitate a really large stack size. But it can run while I try to figure out how to make the whole loop work in Poly arithmetic only. Thanks, Ben -- 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.
