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

@666 jvbasha You'll need to describe how the contour plot that you want is different from the contour plot that you show.

@acer Perhaps incorrect was the wrong term; I didn't mean syntactically. Perhaps logically incorrect or stylistically incorrect would be better. What I mean is that it was more-or-less merely a coincidence that it wasn't syntactically incorrect---even in 2020---the coincidence being that the procedure has no uses, options, or description.

As you've pointed out, the "naked" semicolon terminates a NULL statement, and any statement marks the end of the procedure's header.

The reason that I bring it up is that I think that the OP and many other readers misunderstand both the semicolon and what exactly constitutes a statement.

@janhardo The problem of plotting the tread-riser pattern is complicated by these two issues:

1. There is always one more x-value than there are y-values.
2. It's not clear whether the "extra" x-value is the left extreme or right extreme; that somewhat depends on whether it's a left, right, or midpoint sum.

I thought about a simple way to handle those issues for a long time (about three hours while drifting in and out of sleep (I sleep with my computer with Maple open.)) before I posted my Answer. I think that you're struggling with these same two issues. My solution is to have 3 lists rather than 2: E, F, and X. Lists are like simplified arrays, and it's often better to use them when they'll do the job. X is the x-values of the partition (including the left and right extremes of the interval). E is the x-values where evaluations occur (either the left, middle, or right of each subinterval). F is the y-values, and it's equivalent to applying f to all the values in E. The seq in my plot,

[seq]([[X[k],0], [X[k],F[k]], [X[k+1],F[k]], [X[k+1],0]][],

draws the left-side vertical, the top horizontal, and the right-side vertical for every rectangle. Although this duplicates the interior verticals, I thought that pedagogically that that was the right choice.