From: fateman@cs.berkeley.edu   
      
   I expect that the time to compute an integral depends on   
   two easily quantifiable parameters, and then it also   
   depends on some other stuff too, that probably varies   
   with the particular programming used.   
      
   1. (easy).  The size of the integrand.  For example,   
   integrating f(x)+g(x)+h(x)   will take longer than f(x).   
      
   2. (harder) Assuming some version of a Risch algorithm is   
   used, the complexity of the differential field that has to   
   be constructed to represent the answer, and the cost of   
   solving one or more systems of equations.   
      
   A symbolic answer that cannot be written down on a page or two   
   is not likely to be very useful.   
      
   The timing of Maple routines is, in my experience, contentious.   
      
   That is if most people agree that the answer is, say, a+b+c+1,   
   and most people might concede that they would also accept   
   1+c+b+a  as equivalent, we then can compare the times for computing.   
      
   Maple, on the other hand, may return an answer jumbled up. Say   
   a+c+b+1  on one occasion, and  b+a+c+1  on another.   
      
   It is easy enough to ask  Maple to sort the answer so that it is   
   simplified more-or-less by a conventional ordering criterion.   
     In my tests and papers (way long ago), I contended that the "fair"   
   time comparison should include sort time.   
     Otherwise the Maple answer is not simplified, and not comparable.   
      
   that is, to compare the timing, one should do this:   
      Integrate[....]    (* in Mathematica *)   
   sort(integrate(....))   // in Maple   
      
   Maple fans/ paper reviewers/ generally rejected this view, claiming that   
   the Maple results were simplified without sorting.   
      
   In some tests the time for sorting dominated the calculation, rather   
   surprising to me.  I do not know if the sorting method in current   
   versions of Maple is comparably slow, but I expect that the default   
   Maple behavior, inherent in its hash-coding simplification, has not   
   been changed, and the jumbled-order output is standard for it.   
      
      
   On 1/13/2015 11:04 AM, Axel Vogt wrote:   
   > On 13.01.2015 10:35, Nasser M. Abbasi wrote:   
   > ...   
   >> For example, this integral   
   >> int((B*x+A)*(e*x+d)^(7/2)/(c*x^2+a)^3,x);   
   > ...   
   >> Generates a leaf size of 1,424,430 in Maple   
   > ...   
   >   
   > I guess that by leaf size = number of characters used for display is meant.   
   >   
   > A length of ~ 1.5*10^6 is almost useless and I had not the patients to   
   > wait until Maple answers.   
   >   
   > My naive way in Maple would be to get the partial fractions decomposition   
   > for the denominator. Then one has to compute Int(numerator/(x-t)^k, x),   
   > k=1,2,3 (up to constants). Each of those results have length of ~ 600,   
   > making use of simplify/size (before feeding some constants).   
   >   
   > Now doing it for the full task finally it gives ~ 9000 characters:   
   >   
   >    # find the partial fractions and put them in a list:   
   >    1/(c*x^2+a)^3: convert(%, fullparfrac,x); allvalues(%):   
   >    [op(%)]:   
   >   
   >    # compute the according integrals   
   >    map('w -> Int((B*x+A)*(e*x+d)^(7/2)*w, x)', %):   
   >    value(%):   
   >   
   >    # sum them up and simplify the result   
   >    convert(%, `+`):   
   >    result:=simplify(%, size):   
   >    length(%);   
   >                                   8654   
   >   
   >    # check formally   
   >    diff(result, x) = (B*x+A)*(e*x+d)^(7/2)/(c*x^2+a)^3:   
   >    is(%);   
   >                                   true   
   >   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)