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? Aaron Meurer > > > On 20.04.2012 08:53, Aaron Meurer wrote: >> >> I just remembered something important (I'm not sure why I forgot about >> it before). It's going to be slow with multiple generators simply >> because the polys are slow with multiple generators. This is because >> the recursive dense representation used in the polys is highly >> inefficient for polynomials over many variables. This is because as a >> "dense" representation, it tends to waste a lot of space, and as a >> "recursive" representation, many of the functions are literally >> written recursively, which is expensive in Python (take dmp_mul for >> example). >> >> So we really need to work toward a sparse representation in the polys >> to start to get a real speedup here. >> >> Aaron Meurer >> >> On Fri, Apr 20, 2012 at 1:29 AM, Tom Bachmann<e_mc...@web.de> wrote: >>>> >>>> I tried the expressions from >>>> https://groups.google.com/d/topic/sympy/3y6orHV2_4k/discussion (see >>>> the tarball linked to in the first post). I just tried the small >>>> expression with n=1, but it just hung on the reduction step. Any >>>> thoughts on how to make this faster? Those expressions would make good >>>> stress tests for this. >>>> >>> >>> Well these expressions are *huge*. I will run some timing tests, but I >>> think >>> all parts of the algorithm will break down (i.e. become infeasible >>> computationally) long before that length. >>> >>> >>> -- >>> 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. >>> >> > > -- > 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. > -- 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.