From: Albert_Rich@msn.com   
      
   On Friday, April 29, 2016 at 11:43:40 AM UTC-10, clicl...@freenet.de wrote:   
   > And the winner is ... Rubi!  FriCAS and Mathematica come second in my   
   > view, as the former times out on the last integral but supposedly   
   > returns reasonably compact and real elementary expressions otherwise,   
   > whereas the latter resorts to complex antiderivatives but doesn't slow   
   > down seriously. Maple's return of root objects for the first group and   
   > MuPAD's failure to evaluate the second group should place those systems   
   > last.   
   >    
   > I suppose that allowing not just binomials but also trinomials as   
   > numerator factors accounts for most of the increased Rubi rule count. On   
   > the other hand, the new two term-relations work without exceptions, and   
   > just three rules (of which one merely serves to enhance efficency)   
   > suffice to reduce any pair of exponents in any nondegenerate integrand   
   >    
   >   (A + B*x + C*x^2)*(a + b*x + c*x^2)^m*(d + e*x + f*x^2)^n   
   >    
   > to the standard interval [-1, 0]; compare the (blazingly fast) Derive   
   > code appended below. A number of old Rubi rules (integrand expansion for   
   > integer exponents, special-casing the exponent -2) should therefore have   
   > become obsolete.   
   >    
   > Rubi will presumably suffer a similar size explosion for the P1^m*Q1^n*   
   > S2^p integrands treated in section 11 of the paper you linked to.   
   >    
   > I was actually assuming you had made your original decision in awareness   
   > of the consequences, and were therefore going to defend it!   
   >    
   > Martin.   
   > [...]   
      
   Thanks for announcing Rubi the winner of your product of powers of quadratics   
   integration challenge.  However it should be noted that Rubi won only after   
   improvements were made in response to the challenge.   
      
   You comment that only 3 rules are required to reduce the exponents of   
   nondegenerate integrands to [-1,0].  Unfortunately, their implementation in   
   the real-world is not so simple.  Understandably, Mathematica's pattern   
   matcher does not recognize    
   expressions of the form A, A+B x  and  A+C x^2  as matching expressions of the   
   form  A+B x+C x^2  (that is B and C cannot be 0 in order to match).  So the   
   new Rubi has to have 3 rules for integrating each of the following forms:   
       
        (a+b x+c x^2)^p (d+e x+f x^2)^q   
        (a+b x+c x^2)^p (d+e x+f x^2)^q (A+B x)   
        (a+b x+c x^2)^p (d+e x+f x^2)^q (A+C x^2)   
        (a+b x+c x^2)^p (d+e x+f x^2)^q (A+B x+C x^2)   
       
        (a+b x+c x^2)^p (d+f x^2)^q   
        (a+b x+c x^2)^p (d+f x^2)^q (A+B x)   
        (a+b x+c x^2)^p (d+f x^2)^q (A+C x^2)   
        (a+b x+c x^2)^p (d+f x^2)^q (A+B x+C x^2)   
       
        (a+c x^2)^p (d+e x+f x^2)^q   
        (a+c x^2)^p (d+e x+f x^2)^q (A+B x)   
        (a+c x^2)^p (d+e x+f x^2)^q (A+C x^2)   
        (a+c x^2)^p (d+e x+f x^2)^q (A+B x+C x^2)   
       
        (a+c x^2)^p (d+f x^2)^q   
        (a+c x^2)^p (d+f x^2)^q (A+B x)   
        (a+c x^2)^p (d+f x^2)^q (A+C x^2)   
        (a+c x^2)^p (d+f x^2)^q (A+B x+C x^2)   
       
   Clearly as the number of parameters to rules increases, the impracticality of   
   using pattern matching to implement a rule-based system like Rubi 4 becomes   
   obvious.  Happily however, using a decision-tree to implement a rule-based   
   system like Rubi 5 avoids    
   this fan-out problem.  This is because like your int22 function, a   
   decision-tree's if-then-else function can accept arguments having a value of 0.   
       
   So I need to resist the urge to add more knowledge to Rubi 4, and instead   
   focus my efforts on getting Rubi 5 out-the-door...   
       
   Albert   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)