@mmcdara I'll add more later, but for now I'll mention that Embedded Components can work in the Maple Cloud (ie. via web browser) as well as the free MaplePlayer. Maplets can do neither of those. 

@mmcdara When Embedded Components were first introduced they could only be manually inserted from the palette.

That made developing involved interactive applications more difficult, since (months later, etc) the author would have to crack open their Properties and Action code using the mouse, to make amendments. The need to nest GUI Tables (in order to get nice layout) with hidden borders, and the difficulties of adjusting that by right-clicks, made complicated applications much harder.

For example, I had a tough time writing this application using only right-click for amendments.

But in modern Maple one can embed Components programmatically using DocumentTools:-InsertContent, and one can construct their code programmatically using DocumentTools:-Components and DocumentTools:-Layout. This makes involved application development much easier, and the programmatic construction code can reside in plaintext .mpl files, be revision controlled, etc.

ps. There is a very short interactive least-squares/plotter application on the Help page for the Plot Component programmatic constructor. Building and embedding it requires no right-click or palette mouse effort.

@mmcdara Your worksheet contains no Embedded Components, which is why your calls cannot get or set any values of properties of any Embedded Components.

I attach a revised worksheet in which I have added a single Plot Component from the Components palette. I right-clicked on it and set its identity (name) from Plot0 to Plot1.

Your other attampt at calling DocumentTools:-Do refers to Components with other identities, which is why it doesn't work. I am guessing that you are trying to run Examples from the DocumentTools:-Do command's Help page in your Maple 2015. You seem to overlooked this key paragraph of instructions on that page, right below the call with(DocumentTools) in the Examples Section,

    Insert a Math Expression component and two Text Area components from
    the Components palette.  Change the name of each component to
    expression, from, and to respectively by editing the Name field in the component
    properties.  To display the component properties, right-click (Control-click for
    Macintosh) the component and select Component from the context menu.
    Save the changes and then enter an expression into the Math Expression
    component and integers into the two Text Area components accordingly.

DT-Do_ac.mw

I already showed (the day earlier) that simplify(evalc(...)) could be applied under assumptions to the indefinite integral and that the imaginary part could be thus removed exactly and entirely.

However, as also mentioned yesterday, this approach is inferior to purely numeric integration for the given example because there is additional roundoff error and even greater working precision is required in order to attain decent accuracy.

Using Re instead of up front conversion to exact rationals makes that numeric error effect even worse for this example, and working precision needs to be raised prior to the call to int.

Unfortunately, this is a relatively poor approach to the problem.

@vv Unfortunately that does not work in Maple 17.02. (That is part of the problem.)

But method=ftocms does.

@Carl Love I believe that the remember table helps performance in the case that plot3d is called with the parameter value varying at inner level.

It removes need to be careful about the plot3d calling sequence, at the expense of memory, etc.

I thought that I'd checked, that both solution approaches provide similar, significant performance improvement. 

@Rouben Rostamian  The key is to have parameter delta change less frequently.

Each time the parameter value is changed then the single dsolve-generated procedure loses knowledge of computation (eg. from initial value up to last t-value requested). Hence it's a disaster to have the parameter be changed on the inner loop, as prior work gets unnecessarily recomputed. Carl's solution is to instantiate and retain/store the procedure for each separate parameter value, while mine is to ensure that the parameter changes in the outer loop.

Another possibility is to construct a Matrix/Array of height values, using independent t and delta, then pass that to plots:-surfdata. That approach can make it more explicitly clear that parameter delta can change in the outer loop, ie. less frequently.

This reminds me that I once started on a rough parallel 3d-surface-plot mechanism, optionally allowing parallelization via Grid or Threads packages. For computationally intensive functions the Grid approach can be effective, which might cover this discussion's example. For computationally lightweight numeric functions using a Compile'd/evalhf'd mechanism that utilizes Threads can be effective. (I think I even prototyped using IterativeMaps and a single iteration, for the latter, since it has some of the machinery already handy. The key is to Compile/evalhf the whole mechanism that populates the Matrix, and not just the function to be plotted.) Maybe I'll find some time to dust all the off and make it more generally workable.

@lcz Yes, I knew that before. That's why I didn't bother suggesting that way.

The mixed dashed/solid effect could be constructed from separate lines. It's very easy to do, but slightly less graceful.

Of course, it's only good for a static rendering, and loses its virtue when rotated -- however that's also true for the textplot placements.

This is why I mentioned the partial dashes in the first place. So far, we don't know whether the OP needs them.

@mclaine I toggle the Mapleprimes editor into Source mode, and then use <pre> ... </pre> tags to get that effect.

Mapleprimes used to support inlining of uploaded worksheets with nice 2D pretty-printing, but unfortunately that's been broken for some months now. (It got fixed for a few days, then broke again.)

@Preben Alsholm The difference in the assignment case is interesting.

restart;
f:=proc() local x; x; end proc:

f() + f() + f() - f();

               2 x

foo := f() + f() + f() - f();

          foo := 3 x - x

restart;
f:=proc() local x; x; end proc:

foo := f() + f() + f() - f();

          foo := 3 x - x

f() + f() + f() - f();

               2 x

There is also some degree of automatic simplification occuring within an additional procedure construction. (There is some match up here, with the behavior given by the OP, which had assignments done at the top level.)

restart;
f := proc() local x; x; end proc:

H := proc() f() + f() + f() - f(); end proc;

    H := proc () 3*f()-f() end proc

H();

            3 x - x

restart;
f := proc() local x; x; end proc:

H := proc() f() - f(); end proc;

    H := proc () f()-f() end proc

H();

              x - x

restart;
f := proc() local x; x; end proc:

H := proc() f() + f() - f() + f(); end proc;

      H := proc () 2*f() end proc

H();

               2 x

@mmcdara Thanks, but I had already run in the debugger, and already knew exactly how many times f() gets evaluated in these cases. The debugger cannot help much more than that, here.

An issue with these mixed cases (positive and negative coefficients) is inconsistency between cases and between what happens after wrapping in uneval quotes (relatively speaking). Some amount of automatic simplification occurs. 

The debugger can only show what happens when the evaluation occurs, and that happens only *after* any automatic simplification occurs.

@Preben Alsholm As far as I know (so far) that too is a result of some automatic simplification.

See also the cited example,  f()+f()+f()-f()

The behavior is more complicated in these mixed cases. [edited] Earlier I wrote, "...affected by the order of terms in the sum" but I am not sure. See later comments below.

@mmcdara In general, symbolic integration for expressions containing floating-point coefficients is a not a great idea. This general problem relates to broader areas of symbolic computation, and not just integration in statistics or DEs.

You have omitted to show how M and L figure in your conditions, following "such that".

The wrong use of the `assume` command and the handling of names inside procedure S is the main cause of the problem.

Using the deprecated linalg package, setting Digits to 2, and use of `%` inside procedure S are also poor choices.