This has been asked several times in the past. There are at least half a dozen different ways to approach implementing it.

See responses to these old Questions:  here, here, and here, (or this zany answer).

There are also variations on some of those (ie. the first cited link's Answers) where the InertForms package or manually constructed Typeset 2D Math can display the chain of intermediary and final results in a single output line. This can help get rid of some extraneous brackets in the final display. Personally, I find InertForms to be somewhat clunky -- but I don't recall revisiting the whole question and generating a variant that constructs the Typeset 2D Math behind the scenes.

It could help if you gave us the hardest example that you expect to handle, and describe exactly how you want it to appear. There are too many ways to code it up so that your toy example looks fine but more involved examples (eg. more intermediate steps, things other than simple arithmetic, etc) don't look best. 

Do you need the operators (+, *, etc) to display as usual, or would a lighter gray shade be ok?

In the case of a deeper level of assignment do you want to see each level displayed or just the final numeric values before evaluation? For example, x:=y; y:=z; z:=4.0; and then would input sin(x) show just the additional unevaluated sin(4.0) = -0.757...?

Also important is whether you expect the return-value to be as usual (just the last item in your chain). Is it ok to have the usual return-value, whose usual echoing is suppressed by you (ending your statement with a colon), and your desired chain be merely printed as side-effect? Or can/should the return-value be something that echoes like your displayed chain?

I understand that some of these subtleties may seem hard to grasp, as a beginner. That's why I showed the variety of those cited responses.

Here's an example, necessarily simple because you haven't yet provided a clear description of the data and goal.

Download point_transparency.mw

You are using the wrong command.

StringTools:-Has is for testing for the presence of a single character. Read its help page. That pages states, "Furthermore, if the length of ch is greater than 1, then characters in ch after the first are ignored." So your calls to StringTools:-Has are merely testing for the presence of "_".

You could instead try testing whether StringTools:-Search succeeds, ie. returns a nonzero result.

@Christian Wolinski That's an error message coming out of Maple's Java GUI, rather than the Maple kernel. It means that you've tried to display/print an invalid plotting structure.

What makes you think that RGBA is a valid colorspace specification for the COLOR substructure of a plotting structure? It is not. The valid values are RGB, HSV, and HUE. That is documented on the Maple help page with topic plot,structure

Why don't you answer the question about how the problematic plotting structure was created? Did you construct it directly, rather than obtaining it from some Library plotting command?

I suspect that you are trying to utilize a fourth alpha color channel within a constructed plot structure (related to this recent Question), but that is not supported by the COLOR/COLOUR plotting substructure.

The message is displayed when the GUI tries to print the invalid structure. Depending on what else is in the whole structure some partial plot may be rendered. For example,

Download RGBA_error.mw

The commandline interface emits a slightly different message, eg, Error, invalid COLOUR argument RGBA

The computations are not the same, and are done with different floating-point models by default.

By default the scalar-Vector multiplication is done using hardware double precision (since the scalar and Vector entries are of type numeric and the datatype of the Vector is 'anything'). The result is a datatype=float[8] Vector.

The same effect can be obtained for your second example, involving scalar-scalar multiplication, by casting both arguments to HFloat.

You can turn that off by setting the environment variable UseHardwareFloats to false.

Another way to prevent it is to use an input Vector whose datatype is not 'anything'. For example, it could be 'algebraic'. That's more effort to concoct, and doesn't allow for your pretty 2D Input form of the Vector. I hardly ever see this done.

Download testLA_ac.mw

note: I removed your Numeric formatting of output. I'll add that forcing 20 digits of display for scalar results that return with only default Digits=10 decimal digits is like forcing an untruth, and somewhat obscures what's going on.

@mogi Does this do what you want, for your followup example?

[edit] I'm not sure that I understand your syntax. Couldn't you express it in words?

For a given value of d are you trying to use the maximal value that the expression takes for in a=0..1, or are you trying to use the value of a in 0..1 at which that maximum attains? Or are you trying to compute some else?

Here I use the value of a in 0..1 at which the maximum of the expression attains.

Download plot_max.mw

And here I use maximum value which the expression attains for a in 0..1.

Download plot_max2.mw

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.