This isn't very significantly different in nature from your earlier Question from Dec 9.

Since the Maple commands which deal with external files accept strings to denote the file name, these can be viewed as queries about programmatic string construction. The following code is more about the construction of the string than it is about the save command.

You can use cat, but sprintf (modeled after that in C/C++) is more flexible.

Download sprintf_again.mw

Naturally, if you intend on doing this repeatedly and in a repeating pattern then you could also make a (possibly even 1-liner) re-usable procedure/operator which makes that usage terser.

By default the imaginary unit is captical I in Maple. You can change this to lowercase i with the interface command.

Also, some of the problem inputs had a semicolon terminator before the context-action, resulting in double output.

Also, you don't need to apply the factor command. These products expand and evaluate automatically.

Download 1.3-Complex_Numbers_bad_ac.mw

You could read the .m file, before your call to with.

Download TEST_ac.mw

Alternatively you could LibraryTools:-Save the module to a .mla archive (in stead of save to .m file), and have that be in a libname location.

You could use Norm instead of abs. That is, you could use the double vertical bars, rather than the single vartical bars, in 2D Input.

Or you could use the Normalize command.

I also added evalf; It doesn't seem so useful to get Numeric Formatting to show all rationals as floats.

Download 3d_vector_ac.mw

@salim-barzani You didn't answer what currentdir() returns, and you didn't say specifically what you else had tried. It's more difficult to help when you don't provide the concrete details.

If you're going to use currentdir() then you don't need to concatenate. The purpose of that command is to set the default location.

You might try this, since it you may be able to write to your own User directory.
1) At the start of your code, issue,
   currentdir(kernelopts(':-homedir')):
2) Then you could do the export like,
   ExportMatrix("ST2.txt",...)
data-analysis_ac.mw

nb. When you call currentdir its return value is the previous value (not what you pass as argument). This might have confused you about what you'd set it to.

Alternatively, you could use cat to build up an explicit, fully qualified filename with path, and pass that to the exporting command. In that case you wouldn't need currentdir at all.

If you have problems then you could show us exactly what string was being passed.

Your "test relation" context-panel action is not using your assumptions.

That context-panel action actually consists of a call to the is command, (right-click in left border and Show Command of Document Block, to see).

If such a call is made under your assumptions then is returns true instead of false.

Download mapleintvsmanualint_ac.mw

The following is smaller.

But it does a different collect than you had. It's not just a repair involving the coefficients of your form. (You did not answer my query about whether you needed that particular B[1],B[2] collect, or whether you just wanted something smaller.)

Download coment_acc.mw

There are few adjustments of numeric coeffcients also possible, but it can get tricky since not only might one need to sidestep automatic simplification (using inert %* and content, say) but one might also group only some summands in some subterms.

ps. collecting my intermediate expression wrt [QQ,mu,beta[0],w,lambda] also looks reasonably tidy.

What happens if you enter it like Pi*x*I  , with a capital I?

I understand that a complex number can be entered like 1+2i (no space) in Maple Flow. But -- in contrast to that -- if 1+2*i gets interpreted with `i` as just an unknown name then perhaps one cannot use x*i with lowercase i and symbol x. Just a guess.

You can adjust the numpoints option as you want. This gives even distance between delta2 values.

The interface(rtablesize) but is just so that you can visualize the whole Matrix in Maple.

restart:
interface(rtablesize=100):
h:=z->1-(delta2/2)*(1 + cos(2*(Pi/L1)*(z - d1 - L1))):
K1:=((4/h(z)^4)-(sin(alpha)/F)-h(z)^2+Nb*h(z)^4):
lambda:=Int(K1,z=0..1):
L1:=0.2: F:=10: d1:=0.2: alpha:=Pi/6:
P:=plot( [seq(eval(lambda, Nb=j), j in [0.1,0.2,0.3])],
           delta2=0.02..0.1,
           adaptive=false, numpoints=20);
T:=map[2](op,3,[plottools:-getdata(P)]):
M:=< T[1] | T[2][..,2] | T[3][..,2] >;
ExcelTools:-Export(M, "imparter.xls");

The DE dependent functions are psi(y) and theta(y), but your code tries to extract a value for u(y), which is not even in the system.

Your exact expression contains parameter names Br1, m1, k1, x1 but your code tries to substitute values instead for names Br, m, k, x.

If your analytic solution is supposed to represent diff(psi(y),y) then use that instead of the uneval-quoted 'u(y)' in the eval calls in your printf loop. (You should try and learn -- and remember -- what effect such quoting has.)

Abs_Error_help_acc.mw

The GUI's mechanism for rendering of "usual" animations has the behaviour that only a single instance of each "global" plot feature gets used.

By "global" I mean the kinds of plot feature that is common when one merges plots. For example the axis tickmarks, or the orientation, or the total view, or (in your case) the background image, etc. Those aspects become common/uniquified in every frame, when handled by the GUI's usual animation rendering mechanism.

So, you can't do a usual animation where the view changes with each frame. And you can't do one in which the background image changes with each frame. And (wisely or not) the Statistics:-HeatMap command uses a background image to get nice sharp edges on its rectangles, while reducing the use of GUI resources by avoiding a structure with many rectangles as POLYGONs.

You can, however, show such separate plots by sequentially sending them individually to an embedded PlotComponent. One easy way to get such an effect is to use the Explore command.

Why_cant_I_animate_still_images_like_this_ac.mw

You can experiment with frame duplicates, of floor/ceil/trunc of variable `i`, etc, to alter the frame-rate. Or you could Explore a call to a custom short procedure that did a Threads:-Sleep call before returning a frame.

Naturally, for a construction as quick as your HeatMap you might even Explore direct calls to it (on the fly, not precomputed).

ps. It's not clear how/whether you wanted your go2 procedure to utilize its parameter.

Here is an example that uses Optimization:-Maximize, as well as a 3D plot.

FindingExtractingvaluesdsolvewithspecificconditions_ac.mw

There are a few corrupt blobs of XML in your attached .mw file, ie. unclosed Equation fields.

Here is some recovery (more than I was able to get from Maple itself):

C_Users_Tobia_OneDrive_Desktop_Multivariat_Exercises175_MAS_ac.mw

Let me know if there are additional problems with it.

I strongly suggest that your upgrade from Maple 2022 to Maple 2024, since the latter has far fewer reports on such kinds of worksheet corruption.

Is this the kind of effect that you're after?

You can manipulate the expression temp, etc, and then if you want replace that L[b1] with a number later on.

Download Eval_eval.mw

It appears that you are making multiple fsolve calls. But just three, or many? How large are the systems? Are they all systems of polynomials?

You may be able to tell whether RAM is the problem by looking at your OS (TaskManager, or `top`). I'd expect that it'd take many systems of equations, or very large systems, for that to be the bottleneck in (purely) such fsolve attempts.

But you might well be able to run such multiple fsolve calls concurrently and in parallel (even stopping all, once any root is found) by using either the Grid or Threads packages. In that situation getting the fastest CPU with multiple cores might be most fruitful.

nb. The only parallelism done by Maple with the graphics card is (optionally) some Vector-Matrix multiplication, and that's been mostly surpassed now by the fast regular BLAS (which don't need the mem transfer). It's likely irrelevent here.
nb. Maple GUI resources can be supressed by supressing/avoiding large 2D Math output or input/plots, and so the computational time for your numeric rootfinding is likely unrelated to the RAM/GUI interaction.