It's not clear that you understand the difference between,

forifrom1tondo 

and,

for i from 1 to n do

I'm just guessing, but it's also possible that he has created a Document (or Worksheet with 2D Math input) and now wants to export all the input commands to 1D Maple notation.

If that were the case then one possibility is to use Maple's main menubar File->Export As... and then in the popup toggling the Files of Type drop-menu to be Maple Input (.mpl) . Another possibility in that case, in Maple 2016.2, is to use the undocumented Maple command Worksheet:-WorksheetToMapleText which accepts the .mw filename as a string.

@ZWang I suspect that your task may be achievable by using the exact DE system and the IterativeMaps package (rather than trying to use numeric points generated by DEtools or dsolve/numeric).

One of the issues is that maple's performance with rendering or exporting high density point plots is very weak. In contrast ist handling of images is much better. Trying to convert numeric points to an "image" (float[8] Array) seems like the long slow way to me. Better I think to generate such and image with a tool designed for just that task.

Have you tried the Bifurcation command?

It's worth noting that the submitter gives no details as to the domain of the problem (floats, exact rationals, etc), appears uninterested in the limitations to answering this which are purely theoretical (mathematical) rather than limitations of Maple or other CAS). Also, in several previous threads (some of which duplicate the essential topic) the submitter has been in no way forthcoming with details, or responsive to queries for details.

At this point it hardly matters much whether the submitter simply does not understand the mathematical implications, or it unwilling to consider advice or respond to requests for fundamental clarification, or is just some kind of spamming shill.

The OP has now asked this same question (or what are essential varients of it) multiple times. It's not clear whether the submitter understands why the general problem is not solvable explicitly (on mathematical grounds, not as a CAS limitation). It's also evident that the submitter is not open to solutions involving numeric approximants (nor understands what use those might be).

What is clear, however, is that the submitter is not open to sensible dialogue about this topic. The multiple posts have now become meaningless spam.

@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.