@escorpsy: Quite right, you do not mention locf anywhere, perhaps I should have been clearer. But it is part of the output returned by

with(VariationalCalculus):
EulerLagrange(L,t,[z(t),v(t)]);

as also previously given. Concerning the actual integration over some period of time of some solution to the equations of motion, I am still blank, sorry.

@escorpsy: So if I understand you correctly, you want to calculate the integral of the Lagrangian L for some solution of the equations of motion over some period of time. But why do you take the end of this time interval to be t = L, when this seems to imply that L is both a Lagrangian and a time? Is that intentional?

The complicated equations of motion are somewhat intimidating (and I wonder if there is not some, perhaps analytical, shortcut for obtaining what you want, although I have nothing concrete in mind). But before attempting to do anything with these equations of motion, the quantity locf confuses me. I have no idea what it means or how it arises. The quantity does figure in the code for VariationalCalculus:

showstat(EulerLagrange);

but I do not understand why it should figure as well in the end result, i.e., in the equations of motion, when it does not figure in the Lagrangian L itself. Perhaps someone else can help?

@mj1751: I am afraid that I cannot help you because DTM does not ring any bells with me.

@Kitonum: Thanks for checking the actual efficiencies.

What do you mean by solving a Dirac delta function?

Also, note that your statement

solve(F[k+3]=(eq1+eq2)/((k+3)*(k+2)*(k+1)),F[k+3])

inside your for-loop is pretty trivial, as F[k+3] is already isolated on one side of the equation. Is that really what you had in mind?

@nikkarkian: The only function that should be varied is q(t); therefore, V(q(t)) should not as well be included in the list of functions. Just write

with(VariationalCalculus):
        EulerLagrange(L,t,q(t));
convert(EulerLagrange(L,t,q(t)),diff);

providing the solution in two different, but of course equivalent, forms. Note that because V is unknown, the best Maple can do is apply the chain rule.

Update: Rouben Rostamian beat me to the punch line :-).

@prcls: Your question remains unresolved, indeed. But I think the issue lies with the DifferentialGeometry package itself, rather than with the lessons associated with it. As long as the above reported issues with frames, say, are not fixed, the lessons themselves cannot really be fixed, can they?

@Carl Love: Exactly, the "unstated else" is what I refer to as the "(implicitly) established" equalities. As concerns " reconciliation of the dichotomous nature of Boolean logic with the trichotomous nature of total ordering", I think it is a little over my head :-).

@Carl Love: A clever for loop. The boolean equalities are (implicitly) established only one time each. Thumbs up.

@prcls: Quite right, the frame mysteries continue happily in exercise 5. I do not understand how two E4> prompts suddenly appear inside a series of M> prompts, unless, of course, the creator of the help page has inserted these lines after having created an E4 frame or executed some code related to such a frame. But if such 'jumping around' is the case, then I think it is poorly made.

PS: To remove a frame and its prompt, one would think that RemoveFrame(...) would do the job, but it does not; it only removes the frame, but not the prompt, compare my question Getting rid of a frame. In that thread, Carl Love provides a 'fix', and acer terms, I agree, the behaviour a bug in DifferentialGeometry. Why such a bug has still not been fixed in Maple 2017, I have just checked, I really do not know.

PPS: It is even worse: The code

with(DifferentialGeometry):
DGsetup([x,y,z],E3):
RemoveFrame(E3):
Tools:-DGinfo("FrameNames"),
Tools:-DGinfo("CurrentFrame");

[], E3

tells us that there are no frames defined, as one would expect, but that, nonetheless, the current frame is E3.

@prcls: I have just looked up the exercise you mention. It looks like a mess to me. All the code given there can be boiled down to simply

with(DifferentialGeometry):
DGsetup([x1,x2,x3,x4],M):
TwoFormBasis := proc(M)
   local dim := Tools:-DGinfo(M,"FrameBaseDimension");
   [seq(seq(Tools:-DGform(i) &wedge Tools:-DGform(j),j = i+1..dim),i = 1..dim)]
end proc:
TwoFormBasis(M);

The unintelligible switching between frames in the example is beyond me, and do not really, in my point of view, qualify to be taken seriously.

@vv: Yes, indeed, Typesetting level = Maple Standard makes the error disappear. Thanks a lot, thumbs up, that is quite satisfactory to me. I would never have found that myself.

The delayed evaluation does not work for me, it 'breaks' my coding, because (sticking to the example)

indets(Vector(2,(a) -> 'Matrix'(2,2,(b,c) -> m||a||b||c)));

does not give the entries of the matrices as does

indets(Vector(2,(a) -> Matrix(2,2,(b,c) -> m||a||b||c)));

@vv: Thanks for your feedback. Using delayed evaluation does, however, not fare well with my real code, the example above being, as noted, just an example to bring forward the issue.

Se also the update above.

@acer: Just to be sure (cannot quite tell whether you are aware of the fact), the relation cos(16*x1) = 0 immediately results from cos(8*x1) = 1/2*sqrt(2) by using the second implication of mine one more time, because y = 0 for the latter expression.

@acer: I agree, see my 'Second thoughts' above (your reply and that update of mine seem to have crossed each other). There is indeed the issue of determining appropiate values for the free parameter(s).