i want to evaluate this function . can you tell me which branch i need to checkout ?
On Fri, Apr 20, 2012 at 1:37 PM, 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.) > > > 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<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+unsubscribe@**googlegroups.com<sympy%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/**group/sympy?hl=en<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+unsubscribe@** > googlegroups.com <sympy%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/sympy?hl=en <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.
