@nm When a name=range is given as the second argument, any reference to an indexed variable in the first argument used as the index variable of seq, add, or mul will manifest the bug:

restart:
seq(x[], x[]= 1..4):
x[];
              4

Also, the type assertion checker won't catch the altered value of x:

kernelopts(assertlevel=2):
proc() local x::nothing; add(x[], x[]= 1..4); x[] end proc();
             4

Please don't write an entire paragraph in the title box. Condense it to a one-line summary.

@Gerd I retrofitted both my Answer and the followup with the Orbit procedure so that I believe that they'll work in Maple 18, but I have no way to test that, so let me know.

And, yes, I do use a Maple version that's six years younger than yours.

@Gerd The header of your Question said Maple 2016. I will try to retrofit the code to Maple 18. I think that the relevant change is whether the seq command requires a second argument.

@tomleslie The problem is with Maple's definition of equals, not with its definition of set. Two vectors with equal elements are considered unequal because they have different memory addresses and could potentially become elementwise unequal. Note that I did not say that their equality cannot be determined; no, they are considered definitely unequal.

Let's say you have two boxes, one red and one green. Each box contains the numbers 1 and 2. The red box is delivered to 1 Any Street; the green to 2 Any Street. Are the boxes identical? Definitely not. Are they equal? It's debatable. Are they equivalent? Yes, assuming an appropriately defined equivalence relation. Those boxes are analogous to mutable containers. 

So, we see that the definition of equality (in Maple, in real life, in other software) is somewhat vaguely between identity and equivalence. 

@Gerd To me, it looks like my solution K1:= [seq]~(K) is much simpler than Tom's. Did it not work for you?

@tomleslie This shortcoming---that mutable containers (such as vectors) with equal elements are not automatically recognized as equal---is fundamental to the efficient operation of Maple, so I don't foresee it ever changing. The fundamental workaround is to convert the mutable containers to immutable ones, such as lists. 

@nm The multiline string is valid Maple syntax; you haven't overlooked anything. But it's okay with me if mint is stricter than regular Maple. I want it to flag anything weird, because they may have been unintentional. I take the output of mint as "advice".

That being said, I do think that what mint says in this particular case and the interaction between the string and the if statement are very weird.

@janhardo I agree that there are some weaknesses in VV's proof, which can be easily corrected:

1. It should be verified that the original series converges.
2. The indefinite integration should include a constant of integration.
3. The integrand rather than the intgeral should be converted to a formal power series.

This is not a proof by induction.

Why do you want a workaround? In other words, why do you want the absurd multiline string to pass through mint? I think that mint should be stricter than regular Maple. Personally, I would never use a multiline string.

Here is a procedure for computing orbits under modular matrix multiplication:

Orbit:= proc(L::Vector, M::Matrix, m::posint)
uses LA= LinearAlgebra, LAM= LinearAlgebra:-Modular;
local 
    Mm:= LAM:-Mod(m, M, integer), L0:= LAM:-Mod(m, L, integer),
    Orb:= Array(1..1, [L0]), L1:= LAM:-Copy(m,L0), k, x
;
    for k from 2 do
        L1:= LAM:-Multiply(m, Mm, L1);
        if LA:-Equal(L1,L0) then return [seq](x, x= Orb) fi;
        Orb(k):= L1
    od
end proc
:
L:= <3, 4>: M:= <3, 4*168; 4, 3>:
Orbit(L, M, 5);

Your code doesn't work. If it did work, the answer to your question would be

plot(eval(Am, x= 0), kt= -1..1)

@janhardo The FPS stands for Formal Power Series, so the command convert(F, FPS) is essentially expanding the integral as a series.

If you changed the integral from x= 1..42 to x= 0..42, then you could use 0 as the integrand value at x=0 (because sin(0)=0). Then you'd have an odd number of nodes.

With any number of nodes at least two, you can use the trapezoid rule, but assuming the underlying function is smooth, Simpson's will be far more accurate if you can get an odd number of evenly spaced nodes.

@miasene Please post a worksheet. The issue may be related to version and may be easily fixable.