@panke In order to extend the library path, you might begin by reading the Help page on `libname`, or the relevent section of the Programming Manual.

The main structural difference between a Worksheet and a Document is that the latter has at least one "Document Block".

A so-called Document can have Document Blocks (structurally a container of Execution Groups, which affects their appearance and behaviour). But a Document can also have traditional/plain Execution Groups on their own, each with the red prompt and red 1D plaintext code or black 2D Input.

If you use the menubar's Edit -> Document Blocks -> Create Document Block you can inject that into a Worksheet, and in such a way turn it into a Document -- which happens to have both Document Block(s) as well as Execution Groups proper.

IIRC there is no GUI easy one-shot facility for turning plain Execution Groups (red prompt) into Document Blocks.

If you use that Edit->... concoction from a plain Execution Group then you can subsequently cut&paste its input in as the newly created Document Block's input. (But I don't think that your can cut&paste both input&output together of such an Execution Group without its simply pasting back again in as a plain Execution Group.)

note: Hopefully you are not confusing Worksheet/Document with 1D/2D input mode. I've guessed that you are not.

note: Since a Document can have both Document Blocks as well as plain (solo) Execution groups, the conversion of Worksheet->Document is not strictly unique. Of course, you may want all plain execution Groups turned into Document Blocks. Such a conversion mechanism could be encoded in a reusable Maple procedure -- but not by me in the next few weeks.

note: I'd agree that the terminology is muddled. I find it better to always (and only) capitalize these words when using them in a Maple technical sense.

Note that the following happens if that target result of yours gets evaluated (without faking it via inert operators or similar):

(10/(3*t + 1250))^(1/3);

                             (1/3)
           (1/3) /    1     \     
         10      |----------|     
                 \3 t + 1250/     

Here are a few alternative approaches. (I could have used assumptions, but since you don't appear to be very concerned about whether the "simplification" is always correct I used the symbolic option.)

Download de_ac.mw

There are several t-values at which abs(u2) tends to infinity with x=0. For example, EllipticK(1/2)/2.

You can fsolve for the six t-values in t=-5..5, for x=0.

The attachment shows how Optimization:-Maximize can be used get some approximate values out, hence to illustrate/hint at that.

It also shows fsolve (and solve, for one exact root) acting on the denominator.

plot_ac.mw

Why would you have thought that? Please explain your thinking.

Take x=Pi/4, and take its sin value.  Now take x=2*Pi+Pi/4, and take its sin value. You should get sqrt(2)/2 or approximately .707 for both.

Now consider how to compute arcsin(sin(2*Pi+Pi/4)).

Do you think that the result ought to be 2*Pi+Pi/4? The arcsin command is just going to recieve sqrt(2)/2 from being passed sin(2*Pi+Pi/4).

Here's the kicker: how do you expect arcsin to know whether the sqrt(2)/2 it receives came from sin(2*Pi+Pi/4) or sin(Pi/4)?

You might review some of the basic concepts of trig functions and their inverses -- paying attention to the restricted ranges of the inverse trig functions.

simplify(arcsin(sin(x))) assuming -Pi/2<=x, x<=Pi/2;

         x

sin(arcsin(x));

         x

There are several ways to correct your use of NLPSolve.

Download 4.6_ac.mw

[edit] Your code numerically computes a minimum of an abs call, at a discrete number of N points. You could also plot the smooth curve of the continuous zero-crossing. (Again, there are several ways; I show three ways in the following attachment, one of them using implicitplot.)  4.6_acc.mw
Here is the overlay of that with your 10-point plot:

Even if I "optimize" the size in stored memory of the plotted 2D polygons, the 3D animation can still be quite a burden on GUI resources.

Download IdeaVolume_ac.mw

By "optimizing" the 2D polygons I mean ensuring that each non-empty-area POLYGONS substructure contains only data for the 4 corner points (and not more, ugh), and that the edges of the polygons arise from its style and not from unnecessary line segments. All the subsindets stuff in the attached worksheet is there to try and keep each frame smaller in memory. And the resolution of the extrusion can (reasonably) be kept smaller for smaller rotation, by having it be a function of the angle.

Hard on the GUI. Perform manual rotation at your own risk; I suggest bumping down the partition and frames numbers, then rotating to taste, then reverting and relying on plot-persistence to retain the orientation.  Programmatically specified orientation in animations is a mess.

@zenterix It should not be "obvious" (your word) to you that the two might produce the same plot, since the inputs are not similar at all.

In the example, plot(i, i=1..5), the first argument is a continuous function of i.

In your second example, plot(l[i], i=1..5), the first argument is a list reference which only produces values at a discrete set of integer values.

There are various ways to infom the plot command to sample the second example's first argument at only a fixed number of positive integer values of the independent variable i. But your second example makes use of no such option. The failure is not the fault of the plot command.

You could also re-use your existing code, with a caveat:
It's not clear what you want to happen at the transition. I'm not sure whether you want either, none, or both of the animations to show at t=0. You could change the total number of frames to the odd number 141, say, to get either at t=0 (depending on a strict vs nonstrict inequality). You could also modify the `if` (nesting it, say) to display both at t=0, though I'd guess you might not want that.

(I'm supposing that you would not want to merge two separate animations which both had a t=0 frame.)

Download how_transition_ac.mw

The reason that it works in the procedure is that inside the procedure the (local) name x has been assigned using the set X, ie. lhs~(X). Once you get back to the top-level, outside your procedure, the global name x lacks that value.

Your subsequent top-level replacement could also be accomplished as (simpler, IMO),

    subsindets([dd], suffixed(x), ee -> ee(t))

I think that using globals is awkward, when not necessary. I prefer to use multiple return values, and have the substituted expressions be an additional return value. This would be my preferred approach.  elementwise_equal_ac.mw

Try this, for purely numeric integration:

evalf(Int(abs(1/(x - 2) + 0.5333 + 0.3333*x + 0.1333*x^2), x = -1 .. 1));

                         0.06041415825

By simplifying the integrand (which here sees that x>-1, x<1) before doing the symbolic integration the issue can be avoided.

value(simplify(Int(abs(1/(x - 2) + 0.5333 + 0.3333*x + 0.1333*x^2), x = -1 .. 1)));

                     0.06041419887

That symbolic integration of the simplified inert definite integral happens to produce a correct result and avoid the underlying symbolic problem, but I suggest you not rely on that technique, especially if you are willing to accept a solution with floats. Instead, I'd suggest you try to rely on the first approach I gave of performing purely numeric quadrature.

The following manipulation obtains the same erroneous negative result, and illustrates how it can go awry by, say, failing to split piecewise at every sign change in the integrand. (I used Maple 2022.2).

Download int_neg_ex0.mw

If you plot the integrand in H you can see that it has the wrong sign, for some values.

I will submit a bug report. [edit] It may already be fixed in the version under deveopment.

One way is to use an anonymous procedure.

If the operation involves a command that passes extra arguments at the end then your particular implementation of `&/` allows a terser solution.

Download infix_fun.mw

1) You could change the initial creation of A to,

   A := Matrix(11,11);

and then do your loop.

2) Or you could get rid of the loop altogether and create it as,

   A := Matrix(11,11,(i,j)->i+j-2);

3) Or you could just change the entry assigning line to,

   A(i,j) := i+j;

It happens because A2 is a Matrix, a mutable data structure.

The assignment inside your procedure makes A1 a reference to A. And Matrix A2 is not copied when it is passed in as an argument to the procedure call, so A is a reference to A2.

So your updates to entries of A1 are updates to entries of A, and thus are actually updates to entries of A2. This is part of something that is sometimes called in-place semantics.

If you don't want that behaviour then you can use copy semantics instead, by replacing the line that assigns to A1 as,

   A1 := copy(A);

Changing just that aspect of your example,

Download d_ac.mw

In-place semantics allow for reduced memory use, by not creating a copy unless necessary. This can be a useful and convenient default for mutable data structures; it can gain efficiency for large examples that do not require the copy (because, say, they might not need the original data preserved).

@zenterix How about using ExportMatrix to export purely numeric data to files? You could compare the timing by using (or not) binary (Matlab) file formats supported by that command.

If there are headers (containing nonnumeric data) for the rows or columns then you could save those separately. For large amounts of float data I suspect that it'd be more efficienct to export/re-import without headers (datatype=float[8], say), as Matrix or Array (not DataFrame or anything fancy).

You could generate the filenames in the parent process, and pass one into each Grid process.