@mehdibaghaee There are solid reasons why CodeGeneration is intended to work on multiple expressions in the context of a procedure. The effects of previous statements, and the type information that can be gleaned on a pass through a procedure, can be useful or necessary information for successful code translation.

For that reason alone I don't think that you're going to see much success even if you were to export the worksheet to plaintext (.mpl) format and try and apply CodeGeneration to top-level statements individually. (I'd also expect wrapping such an export in one big proc()...end proc to not fare well, even as a hail-Mary throw.)

If you have a worksheet with 3000 top-level statements then you already have growing problems with program flow-control. (I support that claim partially with the fact that you've also asked recently how to auto-execute whole worksheets without auto-expansion of subsections. And there are hints that your approach to programming with Maple is lacking useful structure.)

Furthermore, I hope you realize that only a specific subset of Maple command calls can be translated. Mostly those relate to low-level operations (usually within a purely numeric context). I've see some LinearAlgebra references in your previous questions, so it may be worth noting that calls to commands even in that package are not generally supported for translation to Matlab. (I have long wanted to add a so-called extension to CodeGeneration which did that, but there are difficulties even with basic things like the handling of 'Matrix' type-checks.) Even a call to the Matrix constructor using dimensions n, where n is previously assigned, can be problematic.

Have you considered placing key computational portions of your code into procedures? There are other benefits for doing so, apart from just code translation.

@sand15 Right, the knowledge that such case-splitting can sometimes lead to verification is useful knowledge. I tried it because I'd seen that kind of thing before.

But since that didn't lead me to a fully programmatic (and straightforward) way to establish the result using only the assume/assuming/is/coulditbe facilities its usefulness is limited. The negative significance is the need for the extra, manual application.

I had found that solve could be used instead, but then noticed that John had already mentioned it.

@taro The particular choice of simplification of the coefficients is rather secondary to the solution, however. The main point I was trying to make in my own Answer was that the common multiplicative power of x (in this example, it happens to be just x) can be obtained programmatically.

@atk1018 That additional (optional) argument passed to the collect command gets applied to the coefficients, following the collection.

If you look at the help page for collect then you can read about the details. In this case the operator u->simplify(u,size) is being passed for the func parameter in the documented calling sequences.

To quote from that help page [bold of key words by me]: "A function may be specified using the optional argument func. It is applied to the coefficients of the collected result. Often simplify or factor will be used."

Are you looking for some kind of field plot?

If you gave no initial conditions then perhaps you could upload or give a link to an image of the kind of thing you want.

Please upload a worksheet that contains an example (of it not working as you hope).

That goal is remarkably poor.

What goal could require this but not have a better programmatic approach?

@AmusingYeti If A and B are both symmetric then (A.B.A)^t = ((A.B).A)^t = A^t.(A.B)^t = A^t.B^t.A^t = A.B.A .

@Earl 

restart;

with(plots):

Tmax:=1/2*arccos(abs(cos(5/m))/cos(5/m))*m-5/2:

display(
  spacecurve([m,Tmax,2*abs(cos(5/m))],m=1..10,
             color=blue, numpoints=1000,
             labels=[m,t,max]),
  plot3d(cos(2*t/m) + cos(2*(t+5)/m),m=1..10,t=-3..3,
         color=gray)
        );

display(
  spacecurve([m,Tmax,2*abs(cos(5/m))],m=0..1,
             color=gold,
             labels=[m,t,``],numpoints=1000),
  plot3d(cos(2*t/m) + cos(2*(t+5)/m),m=0..1,t=-3..3,
         color=gray,grid=[100,50])
        );

@Alexrazz Oh, I see, you want to generate a "manual" worksheet that shows all the steps with explicit commands? Is that right?

If so then there is Good News. Modern Maple now has commands which allow you to (fully programatically) construct an entire worksheet, including regular Input, Output, inlined plots, etc. You then have a choice of either 1) launching that in a new GUI tab, 2) saving it to a file, or 3) embedding it in the current worksheet in a "Task" region. (In the case 3 the embedded input lines won't be executable directly, as they are not inside embedded components. One could also cut&paste those, though. But in cases 1 and 2 it would be fully ready for normal execution by your end-user.)

It seems to me that this might be more in keeping with your "dream" goal. Let me know because I happen to have quite a bit of experience with using that functionality and I could probably get you started.

@Rajab It's not clear to me by looking at your worksheet what βkp, T⊥p/Tkp, or ωcp are, or how it is supposed to represent "maximum growth rate".

So I would say that it's for you to provide a revision to your worksheet which computes the data for those curves as well as explains which variables represent all those named items.

I suspect that the expectation that someone trying to put together the desired kind of plot is far less likely to see best success, if it requires understanding (even part of) the background science. If you can supply the code which can compute (or at least define) the mathematical quantities then we may be able to help you plot them as desired.

@Rajab What do the solid and dotted curves represent, numerically? They don't seem to match the colors' boundaries (which are contours).

@Alexrazz As far as I know there is no fully programmatic way to update (ie. write to) an existing output region, which seems to be what you've described. 

I know many rare tricks, including how to generate coupled input and output regions, where the former can update the latter. But even that requires keyboard shortcut presses or mouse actions in order to act. However the central difficulty is that a MathContainer is not an input region, and is not equipped to act like one. And neither is a Button. And neither is tied to any output region.

It might be possible to rig up a second MathContainer to echo evaluated output like that. It might even be possible to have it show in blue. And be borderless. But centering the result might not be feasible.

A MathContainer is intended primarily for expressions rather than executable statements, in these regards. It does not have a strong design.

Perhaps this might be a good time to explain your broader goals. It happens often that members here get hung up trying to implement some narrow subtask, whereas it later turns out that their broader goals are possible by largely other means. We may still be able to get something like your goals here.

I'm interested to hear about your project, if you can share. For example you might be trying to implement an Embedded Components based general purpose front-end to the Maple library commands. (I have built such a beast, including plotting output. There were hard parts. I opted for plaintext input and typeset output.)

@Alexrazz I'm sorry, but I'm not sure what you mean by "after" the Expression component.

@vv This explanation seems plausible. If the sum of exact, symbolic terms is kept around then each subsequent instance should be uniquified to that same SUM DAG (even if computed anew). That is to say, the SUM would found already in the internal kernel simplification table.

For example, keeping the SUM DAG from being garbage collected (by virtue of the reference to it from S),

restart;
S:=add(sin(k),k=1..10000):
for i from 1 to 10 do
  evalf(add(sin(k),k=1..10000));
end do;

Also interesting (to me at least), using 64bit Maple 2016 on Windows 7:

restart;
T:=add(sin(k),k=3..5):
add(sin(k),k=1..25): # 25 might be a behavioral threshold
op([1..7],%);
           sin(1), sin(3), sin(4), sin(5), sin(2), sin(6), sin(7)
add(sin(k),k=1..25):
op([1..7],%);
           sin(1), sin(3), sin(4), sin(5), sin(2), sin(6), sin(7)