Using a factoring rule, there is no need to convert the type of the coefficients:

> r:=a::algebraic*x^n::posint+b::algebraic*x^m::posint=(a*x^(n-1)+b*x^(m-1))*x:
> applyrule(r,u);
                               x (3.4 x + 1.2 a)

> applyrule(r,nn);
                12                    11                           7
(0.1689228391 10   x + 0.4614468816 10   a[14][t] + 0.9251036956 10  a[15][t]
                      7                           7
     - 0.6275707162 10  a[16][t] - 0.5539558102 10  a[17][t]
                      8
     + 0.2326672199 10  a[18][t]) x

Try exporting the worksheet as RTF. Not a wonder, it but may work.

I can duplicate this error in Maple 16.02, while there is no such error in Maple 17 as Carl has found. So, it may be a problem of the 2-D parser in Maple 16 that was later fixed. As a general advice, better avoid 2-D input as it is a source of headaches...

About its type, f(r) is already recognized as a function (an unevaluated function call):

type(f(r),function);
                              true

and used as such in diverse commands (there are subtleties for some commands though). What do you want to define about it?

This one seems a case of increasing expression size and complication. I have observed instead `simplify/conjugate` as conjugate calls play a significant role in these expressions. Tracing it for Carl's example, shows a pair of executions in Maple 15.01, while they occur in an apparently unending sequence in Maple 16.02. I have debugged this computation in each case (using mdcs), following the succesive executions of  `simplify/conjugate` and calculated for every execution instance the "size" of the argument it receives (length(xx) ). While Maple 15.01 exits after the second execution with a size <1000, in Maple 16.02 this size keeps growing fast.

Maple 15.01:

`simplify/conjugate`
(**) length(xx)
509
(*1*) if type(xx,'{`=`, `^`, set, list, series}') then
(**) length(xx)
969

Maple 16.02:

simplify/conjugate`
(**) length(xx)
509
(*1*) if type(xx,'{`=`, `^`, set, list, series}') then
(**) length(xx)
2674
(*1*) if type(xx,'{`=`, `^`, set, list, series}') then
(**) length(xx)
4214
(*1*) if type(xx,'{`=`, `^`, set, list, series}') then
(**) length(xx)
8506
(*1*) if type(xx,'{`=`, `^`, set, list, series}') then
(**) length(xx)
11282

Your code, as well as Carl's simplified version, runs to the end here (no check of the answers though) from Maple 10.02 to Maple 15.01 (there is another problem in Maple 9.52), while it fails, as Carl found, in Maple 16.02 and 17.

Indeed, the "bug" is basically in this type check:

> showstat(`DEtools/autonomous`,31..33);
`DEtools/autonomous` := proc(des, dvars, ivar)
local aut, temp, tempelem, tempsubelem, tempsubelem2, ndes, ndvar, dvar, i, j, k, dvarslist, vars, deslist;
       ...
  31         if not type(tempelem,constant) then
  32           aut := false;
  33           break
             end if
       ...
end proc

Yet, there is a conceptual issue behind, when a name is considered by the system as a variable and when it is considered a constant? Should a constant be "declared" explicitely as a constant? (Carl's workaround amounts to that). Idem for a variable. The fact is that Maple has no uniform policy on this issue, and it much depends on the context and the command design. Problems occur when conflicting designs come together. Certainly this same issue affects other CAS.

Indeed I have installed both (Maple 13 and Maple 17) plus several other versions. Just install in different directories.

These rewrite rules can be implemented quite strightforwardly by using the procedure applyrule1 (a very handy customization of applyrule):

> r:=[[a,a,a,b,c]=[b,b,b,c,e],[b,b,b,c,e]=[a,c,e,e,e],[a,c,e,e,e]=[a,a,a,b,c]]:
> 
> applyrule1(r,[a,a,a,b,c]);
                                [b, b, b, c, e]
> applyrule1(r,[b,b,b,c,e]);
                                [a, c, e, e, e]
> applyrule1(r,[a,c,e,e,e]);
                                [a, a, a, b, c]
> applyrule1(r,[a,b,[a,c,e,e,e]]);
                            [a, b, [a, a, a, b, c]]

Axel, indeed, I had located already located the reason for that bug, but I had no time to report it here. Yes, you are on the right track, as Maple 17 still computes internally the same result in terms of hypergeom as Maple 9:

> trace(`sum/hypergeom`):
> sum(1/(6*k+1)!, k=0..infinity);
{--> enter sum/hypergeom, args = Sum(1/(6*x+1)!,x = 0 .. infinity)
...
                           converges := true
            t1 := hypergeom([], [1/3, 1/2, 2/3, 5/6, 7/6], 1/46656)
               hypergeom([], [1/3, 1/2, 2/3, 5/6, 7/6], 1/46656)
<-- exit sum/hypergeom (now in `convert/hypergeom/from`[sum]) = hypergeom([],[1
/3, 1/2, 2/3, 5/6, 7/6],1/46656)}
...

So, that the workaround in later versions is:

> `sum/hypergeom`(Sum(1/(6*x+1)!,x = 0 .. infinity));
               hypergeom([], [1/3, 1/2, 2/3, 5/6, 7/6], 1/46656)

And certainly, this result is spoiled in the subsequent stage of conversion to StandardFunctions. See, e.g.:

> trace(`convert/StandardFunctions/noparam/local_transform`):
> sum(1/(6*k+1)!, k=0..infinity);
memory used=1.1MB, alloc=30.3MB, time=0.07
{--> enter convert/StandardFunctions/noparam/local_transform, args = hypergeom(
[],[1/3, 1/2, 2/3, 5/6, 7/6],1/46656), 1, z
...
<-- exit convert/StandardFunctions/noparam/local_transform (now in 
convert/StandardFunctions/noparam) = hypergeom([],[1/3, 1/2, 2/3, 5/6, 7/6],1/
46656) = 1/36*46656^(1/6)*3^(1/2)*`2.718281828...`^(-1/15552*46656^(5/6))*sin(1
/15552*3^(1/2)*46656^(5/6))+1/36*46656^(1/6)*3^(1/2)*`2.718281828...`^(1/15552*
46656^(5/6))*sin(1/15552*3^(1/2)*46656^(5/6))+1/36*46656^(1/6)*`2.718281828...`
^(1/15552*46656^(5/6))*cos(1/15552*3^(1/2)*46656^(5/6))}

For the details of this later "transformation", it may be relevant looking at the (somewhat long) trace from:

> trace(`int/flookup/0fq/formula`):
> sum(1/(6*k+1)!, k=0..infinity);

If I interpret it correctly, this transformation can be implemented quite strightforwardly by using the procedure applyrule1 (a very handy customization of applyrule):

> r:='hyporesult'(a::algebraic,b::algebraic)='hyporesult'('Conj'(a,gamma),b):
> applyrule1(r,'hyporesult'(alpha,beta));
                      hyporesult(Conj(alpha, gamma), beta)

My advice, if you are using the Standard GUI for computations of this complexity, is moving to the command line interface (CLI). This way, you will avoid many "features" of Standard, that are not suitable, designed or optimized for demanding programming tasks.

One way using the command dividend:

> evalindets(a*(b-c),`+`,x->dividend(x,b));
                                 a (1 - c/b) b

The error of the first picture does not occur here (Maple 17 on Linux 32-bit):

> myP(7,2,true,true,true);
memory used=33.8MB, alloc=64.3MB, time=0.73
memory used=84.6MB, alloc=68.3MB, time=1.73
memory used=134.6MB, alloc=68.3MB, time=2.64
memory used=185.9MB, alloc=68.3MB, time=3.50
                                       18
# Almost instant
> myP(8,2,true,true,true);
memory used=236.3MB, alloc=92.3MB, time=4.39
memory used=294.3MB, alloc=92.3MB, time=5.50
                                       21

If it were reproducible for you, you might try debugging it (e.g. see ?debugger ).

@Christopher2222 

There is an interesting difference in Maple 12 between a plot call with the default value for numpoints and a call with the explicit option numpoints=50, as shown by tracing `plot/adaptive`:

trace(`plot/adaptive`):
plot(x^2,x=-10..10);
{--> enter plot/adaptive, args = x, `*`(`^`(x, 2)), x = -10 .. 10, true, 
pmetric_bool = false, resolution = 200, numpoints = 49
...

trace(`plot/adaptive`):
plot(x^2,x=-10..10,numpoints=50);
{--> enter plot/adaptive, args = x, `*`(`^`(x, 2)), x = -10 .. 10, true, 
pmetric_bool = false, resolution = 200, numpoints = 49, numpoints = 50
...

So, actually it may be using numpoints = 49 by default...

This means, from the practical point of view, that using numpoints = 49 is a good setting for obtaining in Maple 17 a plot similar to the default in Maple 12. But, from the technical point of view, why numpoints = 200 produces a worst result? My tentative answer, is as follows. The GUI renderer receives the point data, as pairs of coordinates, and it has to interpolate from of this data to find the location of the pixels that will paint for representing the curve of the function. The algorithm used for the interpolation is not documented, but my guess, based on information trickled from developers, is that an interpolating polynomial is being used, and the degree of the polynomial grows with the value of numpoints (roughly as its cubic root, I guess). But, as I understand it, there is an optimal value for the degree of the interpolating polynomial, and a higher degree may produce too wiggling interpolating curves. And the optimal value of the degree may depend on the smoothness of the function being interpolated. May be that the degree derived from numpoints = 49 is close to the optimal value for x^2, but may be to low for sin(1/x),  say. On the other hand, I think that the change in the underlying plot data structures produced in the recent versions, from lists of software floats to rtables of hardware floats, was related mainly with efficiency improvements, but probably has little or no influence on this wiggle issue.

Then, the key question may be why, since Maple 14, numpoints = 200 is being used by default, when 49 already yields a better result (and would be faster). In the scenario described above, optimizing the value of numpoints would require some symbolic analysis of the function being plotted. But hybrid methods is an area not well developed in Maple for plotting, integration, etc. My guess is that a bunch of functions were plotted, and a value for numpoints was chosen so that the those plots looked better "in the mean".