Your code is not correct, which is why it gives an error message. You are mixing up the syntax for dealing with expressions versus operators. when invoking the plot command.

Either of these pairs of line work, following your preliminary code:
 

Et := delta -> E1(delta) + E2(delta); 
plot(Et(delta), delta = 16 .. 28);
 

Et := delta -> E1(delta) + E2(delta); 
plot(Et, 16 .. 28);
 

But your full original code calls plot with a first argument that evaluates to an operator, yet supplies the plotting domain in the form name=range which is suitable for the expression calling sequence. That's a mismatch.

note: It doesn't matter whether your original call was the 2D input of Et(delta) := delta -> E1(delta) + E2(delta) to create an operator (which, in turn, creates operators!) or to make a remember table assignment (of an operator!). In either case the accompanying call plot(Et(delta), delta = 16 .. 28) would then be invalid, because the first argument Et(delta) evaluates to an operator.

palmmp_ac.mw

You could even do it like so (in 2D as creating an operator which generates operators, or in either 1D or 2D as a remember table assignment of an operator). But it is error prone and dodgy, in my opinion, and will likely come back to bite you. I don't recommend it.

Et(delta) := delta -> E1(delta) + E2(delta); 
plot(Et(delta), 16 .. 28);

You cannot properly use d[1], d[2], and the unindexed name d in this way.

Your assignment to d[1] of an expression containing unindexed name d leads to an infinite recursion.

Rename d[1] and d[2] to something else, for example dd[1] and dd[2].

This is exactly the same kind of recursive assignment mistake that you previously made here (May 22, 2019), and the same fundamental misunderstanding that you made here (Jan 29, 2019) and here (Aug 19, 2017). The nature of the mistakes was clearly explained to you on each of those occasions.

note: Your call to value does nothing, similarly to how you misused it in your previous Question.

Below I am referring to version Maple 2016 (which is the version in which your attachment was last saved).

The behavior of Equations Labels inserted into 2D Input seems broken for the case of backslash characters in names.

It may also be problematic (in a different manner) in the case of such strings inserted as Equation Labels into 1D input.

So perhaps you could use assigned names instead of Equation Labels.

Personally, I prefer 1D Input, no Equation Labels, and nprintf and sprintf instead of convert if I know the type of my input.

  xmaple -standalone

Or, as I usually do it in a terminal,

  maple -x -standalone

IntTutor fails by default to find a complete solution for your example because it meets its step cutoff too soon, because noisy steps like Constant Multiple, etc, are taking up too much of its allotment.

By tagging the rules Constant, Constant Multiple, Sum, and Difference as Understood Rules then the tutor can find the completed solution for this given example, starting with the step to substitute x=sin(u) which it finds automatically.

If the path to a complete solution takes too many steps then the IntTutor will not find it, and it will return the steps that got farthest (even if those don't eventually help). This is what happens by default for your example.

Now, the steps are very verbose, by default. The Constant Multiple rule, for example, is something that I don't care to see applied explicitly (and certainly not when it is applied repeatedly for each term in an expanded sum of integrals!). And there are several other rules that I don't care to see being applied explicitly.

By suppressing visual statement of the application of a handful of noisy rules the IntTutor's total step count cutoff will generally come into play farther along into a problem. And for your particular problem this will allow a complete solution to be found.

In the following attachment the worksheet contains the returned result from IntTutor, after toggle those rules in the menu. And then, after restart, it does a similar thing using the programmatic commands.

Download IntTutor_example.mw

nb. It would be an improvement if the IntTutor automatically utilized the knowledge of which rules had already been programmatically marked as Understood.

Outside of the IntTutor it is also possible to get a complete solution for this problem by using the maxsteps option of the ShowSolution command. (Unfortunately IntTutor does not accept such an option.) Personally I find the constant multiple (and to some extent the constant) rule's steps to make this too verbose and the whole flow less legible. I also think that the default value of maxsteps=25 is too small.

Download IntTutot_maxsteps.mw

Yes, Maple does not promise Digits decimal digits of accuracy for floating-point approximation of compound expressions. That is to say, working with d=Digits working precision does not necessarily ensure d correct digits.

See the Programming Manual. (And consider reading about the fundamentals of floating-point computation, including round-off error. These issues are not specific to Maple.)

Here is one way.

I'm not suggesting that your approach is best. I'm simply showing how it could be attained, as you've described it. I might prefer to just use just a single procedure that admitted values for both a and t as its arguments. I'm not sure what is to be gained by assigning g||k as separate procedures, except if it fits into some broader programmatic flow that you've already developed.

[edit] If your concerned with performance -- especially that following all dsolve calls -- then the best approach may depend on how many such procedures you intend on creating, and how they will be called. In some scenarios (such as a small number of discrete parameter values) you might even be better off instantiating the DE system at explicit values of the parameter in order to construct your g||k. If you utilize the parameters functionality then in your Maple 2015 it may be better to test the current parameter value, so as to not incur overhead that occurs when the parameter value is set on the fly. And some of this may relate to how you use the g||k, eg. whether ot not they are called in an interleaved manner for common t values.

Download Stack_procedures_ac.mw

You have this line, which uses squiggly-brackets (braces).

H := (-lambda+sqrt(-Omega)*{tan(sqrt(-Omega)*xi)+sec(sqrt(-Omega)*xi)})/(2*(v-1));

But {...} creates a set. You should use round brackets to delimit subexpressions.

Did you intend this instead?

H := (-lambda+sqrt(-Omega)*(tan(sqrt(-Omega)*xi)+sec(sqrt(-Omega)*xi)))/(2*(v-1));

And so,

Download syntax_backets.mw

This is to address only the errant "1" that appears as a multiplicative factor in front of the rhs expression.

It doesn't address the issue that the whole rhs fraction is rendered like (num)*(den)^(-1) instead of  num/den ie. \frac{num}{den}

Download latex_mult_patch1.mw

If it works for you then you might consider adding that to your personal initialization file.

Have a look at the ssystem or system commands (or the variant system[launch] ).

Arguments to execute a command can be passed.

If you need to handle a particular example, then tell us the full details(!).

Each time through the loop your code assigns to theta, which wipes out all the previous assignments to indexed theta names.

You could simply change name, for either all the unindexed references, or all the indexed references, to avoid this collision.

seqQ_ac.mw

The attached worksheet overlays a rendered POLYGONS structure with colored pairs of line segments between adjacent points in the list L (with wrap-around connecting L[-1] and L[1]).

You can execute the whole worksheet and then drag the red circle around, inside the axes box. This is done using the Explore command in Maple 2019.1.

The ensuing result seems to agree with what I believe Tom was conveying. The total shaded area is the additive accumulation of shaded polygons whose edges share a common interior coloring (winding parity, or whatever you'd like to call it).

polygonstructureshading.mw

(I cannot properly embed this worksheet here, as Mapleprimes does not support Explore output.)

It seems to balk at the trivial range t=0..0 beng supplied to odeplot.

So, you might animate starting from a small positive value, or add a conditional case to frame.

[edit] I have added examples of each of my previous suggestions below, using Maple 2019.1.

 The first suggestion, to use a non-trivial range, can be done by adjusting either the odeplot or the animate call's range argument. I chose to adjust the range in the odeplot call, so that the paraminfo (running value of animating parameter t) still displays precisely as t=0. in the first frame.

Download mw_ac.mw

ps. I would consider the failure of odeplot in the case of a trivial range (singleton point) to be a bug, and I will submit a bug report.

You could consider this as an example of premature evaluation.

The plot command is seeing just ceil(x) as input, and the `mod` aspect has been dropped prematurely.

That can be resolved in the usual ways: 1) delayed evaluation via right-quotes, or 2) plotting via operator form, or 3) a specialty procedure that returns unevaluated when passed a non-numeric (symbolic) input.

In this situation, choice 3) can be implemented using the extension mechanism of `mod`, rather than the approach of constructing and using a wholly new procedure name.

Download ceilmod.mw

These are not the only ways to resolve this.

No, it cannot be changed in the way you're describing (over and above whatever basic toolbar effects that are your overall Desktop look&feel).