It looks like you have mistakenly split the do-loop code across Document Blocks (or Execution Groups, though there's a slight hint in your posting that you might be pasting into Document Blocks).

Don't press Enter/Return, while typing/pasting in the Block/Group with that do-loop code. That would execute what's entered so far, and split it.

You can use Shift-Enter to get to a new line, when editing in a Block/Group.

If you look at the example in the subsection "Getting the Number of Elements in a List" of Section 4.3 or the Programming Guide (which seems to be your example), then you can see that all the red code of the while-do loop is within the same Execution Group.

That is, the beginning while, and the end do, and all the loop's contents between those, must be within the same Execution Group (or Document Block). Otherwise you'd get those kinds of error messages.

Here's what it might look like, if accidentally split. Notice the left border of the Maple GUI can show Markers that denote the Block/Group boundaries.

Download doc_block_oops.mw

I dug around and found this in the vault (edited slightly to get rid of the infinity, which solve only sometimes removes).

This kind of thing has been asked before, both the basic query about conversion of a real range to inequality relations, as well as simplification of compound examples.

The basic examples are a common flavor, for such there is a dedicated command, as has been mentioned: convert(...,relation).

A related idea is that one can do some simplification for some more involved examples. Also, on output, multiple conditions and multiple solutions can be displayed using Or/And, or %or if one wants, or (last link in end note) union/intersect.

I put the RealRange inputs into 2D form, for fun.

Download some_2D_range_ineq.mw

[edit] It's it's of interest, here are a few old postings on related (or more involved) queries: 1, 2, 3

Given the input ode, why not go straight to,

   has(convert(ode,D),y(x));

without any replacement by Z^N terms.

The simplest (and most effective and efficient way, IMO) is to use a so-called operator form calling sequence of the evalf(Int(...)) or int(...,numeric) or int(...,0..6.0) commands, where the integrand is supplied as an operator/procedure f rather than a function call like f(x).

There are several ways to get it to work instead with something that looks like an unevaluated function call (of x, like f(x), say) as the integrand. But they are often unnecessarily more complicated than the above. I'll show a few such ways.

Download Using_interpolation_ac.mw

You could add the dirfield option, eg.
   dirfield=[11,11]

And you can blend this with other options, eg.
   'arrows'='comet',dirfield=[11,11],arrowsize=1.2

You can save all the assigned names (including just user-defined names), but there's no easy way to save&restore all internal state including memoized results in remember tables and caches.

That's not to say that it's generally impossible (for, say, an expert), especially for Library routines. However there's no stock command for it.

Saving/restoring all the remembered results in all kernel built-ins (eg. evalf, series, etc) might be much harder and perhaps not possible.

Since there are several flavors to this, it would be better if you supplied a concrete, representative example.

Your eval calls attempt to replace names like f__1, f__2, etc, but your expression M actually contains f[1], f[2], etc.

plot_a_ac.mw

Here are a few ways, which you might adjust with options, etc.

My "trick" is to create a system for each param1 value, instead of trying to use it as a DS TransferFunction `parameter` in that routine's technical sense.

[edit: I added plots:-animate]

simple_bode_ac.mw

Are any of these the kind of thing you might be after?

If not, could you provide an example, with input, output, and desired "order" answer? (A worksheet might be best.)

Download asympt_order_q.mw

Using the global (top-level) variable Metric is quite poor.

For one thing, since a Matrix is a mutable data structure then some entry in the toplevel :-Metric might change. And then any already computed invMetric would be wrong. So every call to your module's computational routines would sensibly need to compare entries between :-Metric and some copy (so as to know whether to recompute invMetric. Yikes.

A more usual approach (without "resorting" to Objects) is to have an exported utility which sets both the stored local Metric and its inverse. Then you would simply invoke that where you would previously have redefined :-Metric in your earlier scheme of things.

Download 2024-12-30_Q_Module_Global_and_Local_ac.mw

Here's a somewhat crude use of dsolve's events option to get the points where the diff(x(t),t) hits zero. It could be made fancier.

If you reduce T then it finds less data point and runs faster.

Download saopinjifen1230_ac.mw

We can also overlay that with the odeplot. Here it is for N=10000 (similar effect for larger N, but it all takes longer). Continuing in that code,

solu12(eventdisable={1}):
p1 := plots:-odeplot(solu12, [omega__v, x(t)], 0 .. T, numpoints=50000, color="Niagara Azure"):
plots:-display(
  p1,
  plot([seq(data[2*i], i=1..numelems(data)/2)], color=red),
  plot([seq(data[2*i-1], i=1..numelems(data)/2)], color=red),
  size=[700,400]
);

saopinjifen1230_ac2.mw

Perhaps you could use WorksheetToMapleText from the Worksheet package.

As an example,

currentdir("/home/harpo/skits");
read "slapstick/boguscalculus.mw";

In other words, if you've set currentdir(...) then you don't have to take the trouble to form the fully qualified location (by, say, concatenation).

That's the main point of being able to set the current working directory; it allows you to use relative paths, without having to form them into absolute paths (wrt the root directory).

ps. As a side note, if also you happen to want to obtain the home directory programmatically, you could issue the Maple command kernelopts("homedir") or if it's set as an environment variable in your OS shell, getenv("HOME") .

Does the command currentdir() return a location which is writable by you, when executed by your script approach?

If not, you could set it to a location writable by you, or try passing the full location in the first argument passed to Export. Eg,
   "C:/Users/JoyDivisionMan/LineDensity.jpg"
or what have you, depending on your OS and account details.

nb. We don't know what Maple version and OS you have.

I changed your Post into a Question.

Here is one way of correcting the several mistakes in use of the dsolve result and printf.

I retained your dsolve usage and odeplots.

Download sir_model_ac.mw

ps. It's potentially confusing to people if you use the Maple 2025.0 Beta release for your attachments here./