Automatic parallelization is extremely difficult, and mostly still and open research topic -- so no, Maple does not do that. It generates straight Fortran, not parallel Fortran (of any kind). Without user guidance, this would be rather difficult. I don't know if it is possible to do what you want with makeproc -- I have never seen that kind of functionality documented anywhere. It certainly sounds useful, hopefully it will be implemented.

Maybe even a link to your full code? Without it, it is fairly difficult to help, as there are no really general solutions for the types of problems you are encountering. I have used CodeGeneration and codegen a lot (and have also run into many limitations), but I usually can find ways around those limitations. [If you search for CodeGeneration and my name on primes, you'll get links to some papers which I co-authored that use these facilities rather heavily, and successfully].

That last integral is a Mellin transform which Maple knows about [though why int does not know about inttrans[mellin] is still one of those ageless mysteries]:

> assume(a::real,b::real);
> int(exp(-t)*t^(a-1)*cos(b*ln(t)),t=0..infinity);

             infinity
            /
           |                     (a~ - 1)
           |          exp(-t~) t~         cos(b~ ln(t~)) dt~
           |
          /
            0

> f := exp(-t)*cos(b*ln(t));

                     f := exp(-t~) cos(b~ ln(t~))

> convert(inttrans[mellin](g(t),t,s),int);

                      infinity
                     /
                    |                   (s - 1)
                    |          g~(t~) t~        dt~
                    |
                   /
                     0

> inttrans[mellin](f,t,a);

       | GAMMA(a~ + | b~ | I) | cos(arg(GAMMA(a~ + | b~ | I)))

I should have converted this to a 'prettier' format, but no time right now.

The problem is that you are printing it as an *expression*, not as a *computation sequence*. The following sequence of functions shows how: assume(g>0,ee>0,t>0,c>0,sigma2>0,v>0,a>0,xbar>0); t22 := Re((1/2*(a^2+2*sigma2*(c+g*(ee+i*v)))^(1/2)*exp(.5*a*t)/ (1/2*(a^2+2*sigma2*(c+g*(ee+i*v)))^(1/2)*cosh(1/2*(a^2+2*sigma2*(c +g*(ee+i*v)))^(1/2)*t)+.5*a*sinh(1/2*(a^2+2*sigma2*(c+g*(ee +i*v)))^(1/2)*t)))^(2*a*xbar/sigma2)): t22 := subs(i=I, .5=1/2, t22): ans := evalc(simplify(t22)): codegen[optimize](ans); which returns

         2          1
  t1 = a~ , t3 = -------, t6 = exp(t~ t3 xbar~ t1), t7 = a~ xbar~,
                 sigma2~

               2                                              2
        t8 = t1 , t9 = sigma2~ t1, t12 = g~ ee~, t15 = sigma2~ ,

                2          2                          2          2
        t16 = c~ , t23 = g~ , t24 = t23 t15, t25 = ee~ , t28 = v~ ,

        t32 = (t8 + 4 c~ t9 + 4 t12 t9 + 4 t16 t15 + 8 t12 c~ t15

                                 1/2
         + 4 t25 t24 + 4 t28 t24)   , t34 = 2 t32, t35 = 2 t1,

        t37 = 4 sigma2~ c~, t40 = 4 sigma2~ g~ ee~,

                                     1/2        t~ t42
        t42 = (t34 + t35 + t37 + t40)   , t44 = ------,
                                                  4

                                                      1/2
        t45 = cosh(t44), t48 = (t34 - t35 - t37 - t40)   ,

              t~ t48
        t50 = ------, t51 = cos(t50), t54 = sinh(t44), t56 = sin(t50),
                4

              t51 t45 t42   t56 t54 t48                        2
        t61 = ----------- - ----------- + t51 t54 a~, t63 = t61 ,
                   2             2

              t51 t45 t48   t56 t54 t42                        2
        t72 = ----------- + ----------- + t56 t45 a~, t73 = t72 ,
                   2             2

                  1
        t75 = ---------, t79 = t75 t61 t42 + t75 t72 t48,
              t63 + t73

                                                     2      2
                                                  t79    t85
        t85 = t75 t61 t48 - t75 t72 t42, t88 = ln(---- + ----),
                                                   4      4

                                           t85  t79
        t91 = exp(t88 t3 t7), t93 = arctan(---, ---),
                                            2    2

        t97 = cos(2 t93 t3 t7), t98 = t97 t91 t6

which, as a C/C++ program is small and even reasonably efficient!

That is seriously not competitive with any of the other products that Maple pits itself against. And even in Classic too! Well hopefully Maplesoft will fix this before someone publishes a third-party review of systems where this comes up as a glaring hole in Maple.

Writing fast Maple code is a bit of an art -- without details of your code, we won't be able to help you. Do remember that for things like plotting dynamical systems, Maple is about 100 times slower than C. Of course, writing the code to do it in Maple is about 1000 times faster than C. Kind of depends which parts of your time is more valuable!

LinearAlgebra[LinearSolve] on rank-deficient matrices with exact entries will return a set of solutions with fresh symbols in it, to represent the fact that you have arbitrary subspaces of solutions. Of course, for M*x=x, you need to do LinearAlgebra[LinearSolve](M-LinearAlgebra:-IdentityMatrix(n), LinearAlgebra:-ZeroVector(n)); where n is the dimension, but that is easy.

I think this implements what you want. The functionality is buried in there, but still accessible -- look at Worksheet[Comparator][CompareFiles] for example.

Digging into sum, one encounters the "magic numbers" in SumTools:-DefiniteSum:-NumericRange. Basically, if the summand is not a polynomial and the number of terms to sum is <= 1000, then add is used. If the summand is a polynomial and the number of terms is greater than degree^2+200, then the indefinite sum is used. These numbers (1000 and 200) are rather ad hoc, and are in fact the same numbers as were used in Maple 8 [and my guess is that they go much further back]. Since these numbers were chosen because of timings done on ancient machines using long-forgotten methodologies, I would be rather willing to be that they are now completely "magic" constants that have no other explanation than having been chosen in the deep dark past.

Clearly you mean for n to be an integer -- but Maple does not know that! Notice that

> (-1)^12.39485739854;
                    0.3243412235 + 0.9459401518 I

So the reason you are getting a blank plot is that all the values are complex. The other issue is that what you posted (-1)^n + n^3 / n^3 +4n^2 + 8 more than likely is missing 2 sets of parens: ((-1)^n + n^3) / (n^3 +4n^2 + 8) (otherwise what's the point of n^3/n^3 ?). One way to get a plot is as follows: plot(eval( ((-1)^n + n^3) / (n^3 +4*n^2 + 8), n=floor(x)), x = 1..infinity); which, as expected, shows a staircase effect before it gets smoother.

assume(m::real): p := PIECEWISE([exp(m)-exp(-m), m <= 0],[0, 0 < m]) = min(0, exp(m)-exp(-m)); simplify((lhs-rhs)(convert(p,piecewise,m))); returns 0 quite quickly. It will likely always be the case that Maple has some knowledge about particular identities that 'is' has not been taught about yet. One can easily rephrase most of what Maple does as a question to 'is'. To have 'is' be as powerful as Maple, it would have to be given full knowledge of all the problems that can be stated in Maple, and which routines have some required knowledge, which is clearly both a monumental task and a moving target. The better way to attack problems such as the one above is to use simplify rather than is.

I think the problem is that MapleTA uses $ to mean one thing, while Maple itself also uses $ to mean something else entirely. In Maple $ is an older form of seq -- which is what is being used in your solve line. If you rewrite your first solve line using seq twice, I am guessing that that should fix things. There really ought to be warnings about this in the MapleTA documentation!

Much to my amazement, the old (and hard to use) stats package had exactly this functionality. For a CDF, icdf was the 'inverse' CDF. And ChiSquare is implemented. I am really amazed that this functionality does not seem to be implemented in the Statistics package! Up to now, Statistics seemed to be to completely supercede stats, but you've just found a hole in my belief.

Trying that integral symbolically for m=3 reveals a bug somewhere in Maple:

> P:=(x,m)->sqrt(x)/(sqrt((x+m)^2-1)*(x+m+sqrt((x+m)^2-1)));

                                       sqrt(x)
    P := (x, m) -> -----------------------------------------------
                               2                           2
                   sqrt((x + m)  - 1) (x + m + sqrt((x + m)  - 1))

> assume(m::RealRange(1,5));
> g := int(P(z,3),z=0..infinity);

                          /
                          | 3      2
  g :=      lim       2/3 |z  + 6 z  + 8 z
       z -> infinity      \

                                      1/2
            1/2  1/2           (z + 4)      1/2    2           1/2
         + 2    z    EllipticF(----------, 2   ) (z  + 6 z + 8)
                                   2

                                        1/2
              1/2  1/2           (z + 4)      1/2    2           1/2
         - 3 2    z    EllipticE(----------, 2   ) (z  + 6 z + 8)
                                     2

            2   2           1/2
         - z  (z  + 6 z + 8)

              1/2            1/2   1/2   2           1/2
         + 3 2    EllipticE(2   ) z    (z  + 6 z + 8)

                                                      \
            1/2            1/2   1/2   2           1/2|   /   1/2
         - 2    EllipticK(2   ) z    (z  + 6 z + 8)   |  /  (z
                                                      / /

          2           1/2
        (z  + 6 z + 8)   )

> with(MultiSeries);

  [AddFunction, FunctionSupported, GetFunction, LeadingTerm,

        RemoveFunction, TypeForest, asympt, limit, multiseries,

        series, taylor]

> asympt(op(1,g),z);

                  1/2                     1/2                 1/2
                 2                       2                   2
  10/3 EllipticK(----) - 2/3 I EllipticK(----) - 4 EllipticE(----)
                  2                       2                   2

              1/2            1/2         1/2            1/2
         + 4 2    EllipticE(2   ) - 2/3 2    EllipticK(2   )

                   1/2           3/2            5/2
           11 (1/z)      14 (1/z)      637 (1/z)         1
         - ----------- + ----------- - ------------ + O(----)
                3             3             60            3
                                                         z

> evalf(%);

                                                 1/2
  2.930475954 + 3.388852336 I - 3.666666667 (1/z)

                            (3/2)                    (5/2)      1
         + 4.666666667 (1/z)      - 10.61666667 (1/z)      + O(----)
                                                                 3
                                                                z

> evalf(Int(P(3.0,x),x=0..infinity));

                             0.2971729372

If I had to guess, I would think that it is the symbolic definite integral which has a branch-cut problem. [Note: this was in Maple 10, as I don't have 11 installed on my laptop yet].

I am surprised that subs has not been eradicated from all but the back pages of the Advanced Programming Guide, as well as not appearing in any context-sensitive menu. It use is very subtle, and eval is almost always what users want anyways. Only on rare occasion will an advanced Maple programmer really want (or need) subs.