14 years, 0 days

## factoring rule...

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
```

## Export as RTF...

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

## Why can't differentiate...

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...

## define a function...

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?

## simplify -> complicate...

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
```

## code on different versions...

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.

## Bug in DEtools[autonomous]...

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.

## No conflict...

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

## rewrite rules...

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]]

```

## the reason for that bug...

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);
```

## by applyrule1...

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)

```

## Try with the CLI...

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...

One way using the command dividend:

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

## No error here...

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 ).

## Interesting difference...

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
...