On 20.04.2012 19:50, Aaron Meurer wrote:
On Fri, Apr 20, 2012 at 2:07 AM, Tom Bachmann<e_mc...@web.de> wrote:
That could be true. The groebner algorithms actually use a minimal sparse
representation internally. But running trigsimp_groebner on smallExpr for me
hangs on "a * d_hat - b * c_hat" - (not even the conversion to sparse or
reduction, yet) just a multiplication of (huge) polys.
As I said, I'll run some timing tests to figure out the bottleneck. But I'm
not sure this algorithm can work with such huge expressions. Even the
"staircase" function (which just enumerates all monomials below a certain
degree) takes ages (I am not sure why, yet. The dense representation does
not seem to be a problem.)
Is staircase() different from monomials()? According to the docstring
of monomials(), this suffers from combinatorial explosion. Where
exactly is staircase used?
It avoids some (hopefully many...) of the monomials by taking only those
not divisible by leading monomials of the groebner basis. (These
monomials form a basis of the quotient space, which is the most basic
property of groebner bases.)
As I said earlier, the algorithm essentially tries general fractions of
increasing degrees and sees of they are equivalent to the fraction we
are simplifying.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@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.
