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.

Here's how your stated target can be found using collect, as well as some alternative metrics.

I also show an alternative result, which scores better than your proposed target on all four metrics shown.

Download crush_ex0b.mw

@zenterix 

If you keep/create your packages in the following pattern then the lib subdirectories get added to libname automatically upon relaunch.

  $(HOME)/maple/toolbox/mypackage/

where the .mla for that package is put in a subdirectory named lib.

You can also put the source under that directory.

And so all the source, along with the .mla, can be under that mypackage directory.

And similarly for mypackage2, mypackage3, etc.

In new Maple sessions the kernel will pick up the lib subdirectories for all such, and add them to libname.

The key here is putting them under this special location: whatever this returns,

  cat(kernelopts(homedir),"/maple/toolbox");

This approach removes the need to use any initialization file. Thus any tricky editing of an initialization file is wholly unnecessary.

And it lets you keep each package's source and .mla under its own directory. (Which you wanted, for github.)

The value of libname gets further augmented (in subsequent sessions) simply by adding another package in another such directory tree.

Side-note: You can also programatically create a self-installing file which unpacks any or all of .mla, .help, source, and build-scripts to the equivalent directory on someone else's machine. (This knows where to place these toolbox files regardless of operating system: Linux, MS-Windows, or OSX.)

This is the scheme Maple uses for its own add-on toolboxes. Why reinvent the wheel?

As documented on the procedure Help page, within a procedure a reference to a local gets only single level evaluation.

In contrast a declared global gets fully evaluated.

Here are a few notes:

Download local_eval_notes.mw