that works in this case where 'match'  does not:

solve(identity(5*cos(2*t)+sin(2*t)=c*sin(w*t)+d*cos(w*t),t),[c,d,w]);
[[c = 1, d = 5, w = 2], [c = -1, d = 5, w = -2]]

And some packages have matchers of their own. In short, there is a bunch of code around but not a single facility that can be relied upon.

should replace exp(q*Pi) with alpha^5. Why do you say that I would not want this rule applied?

I may like such tricks as a "sport", but I dislike to be distracted when doing mathematics and I am forced to use them for no good reason. Nothing more than  a "normal" syntax, like that I have  used, should be required to produce the expected result.  I do not  think  that using here something like  "n::imaginary(fraction)"  qualifies as  "normal"  for anybody.

The example above is only one out of many.  Just changing the example a little bit:

seq(applyrule(exp(n::integer/5*q::name*Pi)=alpha^n,exp(i/5*q*Pi)),i=1..4);

requires thinking the trick again. So, my point here is not how to do this particular example, but  to exemplify a "generic" problem.

If this level of "sophistication" and "fine-tuning" is required to make 'applyrule' work for such a simple example, it shows to me that the pattern-matching system still needs much more development  to become useful for the ordinary user.

Let us continue here .

and with more evaluations:

plot/adaptive:   using evalf

plot/adaptive:   produced    100    output segments

plot/adaptive:   using    100    function evaluations

 

and with more evaluations:

plot/adaptive:   using evalf

plot/adaptive:   produced    100    output segments

plot/adaptive:   using    100    function evaluations

 

Apparently it is not bringing any problem on this side.

The code in this case  is  quite  simple:

showstat(`type/anyindex`);
`type/anyindex` := proc(expr)
   1   type(expr,'indexed') and type([op(expr)],[args[2 .. nargs]])
end proc

It should be not difficult to improve it. On the other hand, apparently. it does not seem that its improvement requires investigation of better algorithms.

It remains the issue of whether any change here could affect elsewhere. I wonder whether there is a straightforward method to obtain a "naive" measure of this risk.

I mean, eg. if this particular piece of code were not called elsewhere in the library, it could be said that there is no risk at this level. On the other extreme, if it were called at 1000 points, chances are that the risk is large.

will need also to be independently listed. Either to take care, avoid or try to patch if possible and needed.

I find that pattern matching is a basic and needed feature where Maple is weak and I would have expected much more development in this area.

See eg this article in Wikipedia.

You may verify the solutions of 'dsolve' using 'odetest'. In Maple 11.02:

odetest(Y,DE17);
                 Dirac(t - 2 Pi) + 2 Dirac(t - 3 Pi)

odetest(y(t)=Y5,DE17);
                                  0

It is a regression bug. In Maple 10.06 it works fine:

Y:=dsolve({DE17,y(0)=0,D(y)(0)=0},y(t));
Y := y(t) = -(Heaviside(t - Pi) - Heaviside(t - 2 Pi) + Heaviside(t - 3 Pi)) sin(t)

odetest(Y,DE17);

                                  0

The integrand

> f:=arccos(x)/(1+x^4); 

and its numerator, in particular, are smooth and bounded functions within the interval [0,1]. So, for the evaluation of the integral J

> j:=u->
> Int(u,x=0..1):
> J:=j(f);
                                     1
                                    /
                                   |   arccos(x)
                             J :=  |   --------- dx
                                   |     4
                                  /     x  + 1
                                    0

I will expand arccos(x) in a Taylor series and integrate term-by-term:

> (fn,fd):=(numer,denom)(f):
> fns:=convert(fn,FormalPowerSeries);
> tk:=op([2,1],fns):
                            /infinity                            \
                            | -----   /          (-k)  (2 k + 1)\|
                      Pi    |  \      |  (2 k)! 4     x         ||
              fns := ---- + |   )     |- -----------------------||
                      2     |  /      |          2              ||
                            | -----   \      (k!)  (2 k + 1)    /|
                            \ k = 0                              /

We get two pieces:

> g1:=op(1,fns)/fd;
                                          Pi
                                g1 := ----------
                                          4
                                      2 (x  + 1)
> g2:=subsop(1=tk/fd,op(2,fns));
                        infinity
                         -----   /          (-k)  (2 k + 1) \
                          \      |  (2 k)! 4     x          |
                  g2 :=    )     |- ------------------------|
                          /      |      2             4     |
                         -----   \  (k!)  (2 k + 1) (x  + 1)/
                         k = 0

So, the integral of g1 is:

> J1:=j(g1);
                                     1
                                    /
                                   |       Pi
                            J1 :=  |   ---------- dx
                                   |       4
                                  /    2 (x  + 1)
                                    0
> J1v:=value(J1);
                 2  1/2
               Pi  2              1/2         1/2             1/2
        J1v := -------- + 1/8 Pi 2    ln(2 + 2   ) - 1/16 Pi 2    ln(2)
                  16

While the integral for the series becomes formally:

> subsop(1=j(op(1,g2)),g2);
                  infinity    1
                   -----     /            (-k)  (2 k + 1)
                    \       |     (2 k)! 4     x
                     )      |   - ------------------------ dx
                    /       |         2             4
                   -----   /      (k!)  (2 k + 1) (x  + 1)
                   k = 0     0
> value(%):
> J2s:=map(simplify,%);

       infinity
        -----
         \
J2s :=    )
         /
        -----
        k = 0
    /   (-2 k - 2)        /                                Pi k      \\
    |  2           (2 k)! |-LerchPhi(-1, 1, 1/2 - k/2) cos(----) + Pi||
    |                     \                                 2        /|
    |- ---------------------------------------------------------------|
    |                                   2     Pi k                    |
    |                     (2 k + 1) (k!)  cos(----)                   |
    \                                          2                      /
> sk:=op(1,J2s):

So, formally, J=J1v+J2s. Here, the terms with k odd are problematic. So, for a numerical check of this result, I will sum even and odd terms separately. First, the sum of the even terms:

> eval(sk,k=2*m):
> sm:=simplify(%) assuming m::posint:
> Se:=Sum(sm,m=0..infinity);
         infinity
          -----   /                    m                               (-m)\
           \      |    (4 m)! (-Pi (-1)  + LerchPhi(-1, 1, 1/2 - m)) 16    |
   Se :=    )     |1/4 ----------------------------------------------------|
           /      |                            2                           |
          -----   \                    ((2 m)!)  (4 m + 1)                 /
          m = 0

I have not got a closed form for this sum, but there is no problem to evaluate it numerically. Now, for the odd terms, evaluation of these terms produce error messages: "Error, (in LerchPhi) numeric exception: division by zero". And limit, with factorials replaced by GAMMA calls:

> skc:=convert(sk,GAMMA,factorial);

remains unevaluated (both "ordinary" or MultiSeries). Clearly there are singularities, but it seems to me that they are "mild" in the sense that the limit exist. Eg, a plot like:

> plot(skc,k=0..5);

shows a quite smooth curve. So, in the assumption that these limits exist, I evaluate a numerical approximation of these limits as a mean of the value of the terms with k shifted a bit below and a bit above, and add a number of them:

> Digits:=15:
> So:=1/2*(add(evalf(eval(sk,k=2*i+1+10^(-6))),i=0..50)+
add(evalf(eval(sk,k=2*i+1-10^(-6))),i=0..50));

                        So := -.348302048743784e-1

Then, adding the numerical evaluation of these three terms:

> evalf(J1v+Se)+So;
                        0.922570909713502

I get a result that compares quite well with:

> evalf(J);
                          0.922548175702252

Clearly, there is a "delicate" balance between the value of Digits, the magnitude of the "shift" and the number of terms in So.

The option for grid lines in Standard GUI allows for ploting vertical grid lines. You can plot the horizontal ones with eg:

plot( [0,2], x=0..2, color=black, axes=none );

and complete the square with two vertical grid lines. It does not look bad.

for the result of this integral is here:
                                                           2  1/2
          1/2         1/2             1/2         1/2    Pi  2
 1/16 Pi 2    ln(2 + 2   ) - 1/16 Pi 2    ln(2 - 2   ) + --------
                                                            16

+

infinity /   (-2 k - 2)        /                                    Pi k \\
 -----   |  2           (2 k)! |Pi - LerchPhi(-1, 1, 1/2 - k/2) cos(----)||
  \      |                     \                                     2   /|
   )     |- --------------------------------------------------------------|
  /      |                                  2     Pi k                    |
 -----   |                    (2 k + 1) (k!)  cos(----)                   |
 k = 0   \                                         2                      /

Note that in this series there is an issue with odd terms, but a numerical check (through a workaround) is OK. Details, sometime later.