The Fractals:-EscapeTime commands produce images (in the float[8] rtable sense), not plots.

You can "animate" a discrete number of images (or even calls to the Mandelbrot command at modest size, it's that fast) using Explore.

But you cannot nicely export that animated rendering to an external file. Maple's directly export functionality is limited to exporting a sequence of actual plots. Converting those images (rtables) into, say, densityplots would produce results too large and unwieldy for the GUI and its export drivers to handle well (if at all).

What you could do, instead, is export the images (rtables) directly to separate external image files (.gif, .png, what have you), using the ImageTools:-Write command. And then use an external 3rd party tool on your OS to assemble a movie format file (mpeg2, mp4, .gif, etc) from those.

Here are two alternatives to plots:-display, one using DocumentTools:-Tabulate and the other using DocumentTools primitives.

If you really want you could use more Table nesting (and suppressed borders) to get precisely the layout you showed. Perhaps more effort than it's worth...

(Sorry, I don't think that this forum will properly inline this worksheet here.)

question5_ac.mw

I don't why you wouldn't expect a(i)=0 and c(i)=0 to follow from your given a(0)=0 and c(0)=0. Perhaps you (or I) have made a mistake?

For fun, procedures Ap and Cp below take a0,c0 initial values as 2nd and 3rd arguments respectively.

The procedures Ap and Cp are programmatically generated from the recurrence equations. (I didn't feel like wrestling with rsolve.) So you can regenerate them for some modest edits of the equations.

In the example I use a0=0.1 and c0=0.1.

Download rsolve_for_system_of_recursive_equations_acc.mw

There are various ways to programmatically make the result appear in terms of J/mol as units. See attachment below for three of them.

It numerically better to round final results to 3 digits instead of calling evalf(...,3) or evalf[3](...) which do computations at lower precision and can incur unnecessarily greater roundoff error than usual.

I am deliberately avoiding using right-click units-formatting or numeric (float) formatting via the GUI.

(For some reason this forum is not letting me inline my revised Document, sorry).
Download question4_ac.mw

In terms of programmatically determining significant digits you might try either the Tolerances or the ScientificErrorAnalysis packages, depending on your concept of error in the supplied input float values.

You wrote that you knew how to construct the filled 2D plot. Great.

You can transform a 2D plot to 3D, for some terse code for your goal.

I shift (before and after, to positive y) to allow the filled portion to survive the transformation more nicely.

Download 2Dfill_transf_3D.mw

You asked about doing the loop without the list from 1 to 5 for the index. Here below is another common loop syntax choice.

The rest is also done more simply, without duplicated input of those multiples of Pi, etc.

Download exp_seq.mw

Your examples (so far) don't require evalc or convert(...,radical).

If you want it terser you could also begin that loop as,
     for i to 5 do
which would start by default from 1.

The problem is that you've made several mistakes. It's not a configuration issue.

Your list li is created with roll, but it ought to be calls like roll() .

You call solve on f(x), but the procedure you created was assigned to g, not f.

If you want floating-point results then you can use fsolve here, rather than solve.

Download rand_usage.mw

You may use expand for Q2.

Both Q1 and Q2 require fixing the problem of the erroneous multiplication syntax.

Download Q20220110_ac.mw

You need to apply Re (or Im) to the call y(x) in the view(s), rather than to sol.

restart;

odesys := {diff(y(x),x) + I*y(x) = 0, y(0) = 1}:
sol := dsolve(odesys, numeric, range=0..1):

plots:-odeplot(sol, [x,Re(y(x))], x=0..1);
plots:-odeplot(sol, [x,Im(y(x))], x=0..1);

plots:-odeplot(sol, [-Im(y(x)),Re(y(x))], x=0..1);

# Or, if you don't want to use odeplot,
plot(t->Re(eval(y(x), sol(t))), 0..1);
plot(t->Im(eval(y(x), sol(t))), 0..1);

etc.

Here's another simple implementation, generating new unassigned constants for each call (and not adding such if it returns an unevaluated int call).

Download intconst.mw

Naturally you could also add that procedure to a custom package (module, loadable using with). Then you could name it int and call it that way.

Download intconstpkg.mw

I don't think that you should try to change the behaviour of :-int itself (via unprotect) lest some things break internally.

I find the goal here to be slightly suspicious. Having said that,

Download alias_oof.mw

Others have addressed your direct query about the persistence of 0.0*I.

You might also be interested to know that the plot command can ignore zero (or very small) floating-point imaginary artefacts, in order to produce the desired result.

I suppose that you are examining the effects of transforming your earlier integral, and in particular the result of some change of variables (possibly on an indefinite integral, then using FTOC) where the end result is better behaved numerically. Ie,

One possibility is to convert the form, manually.

Download _zero_times_imaginery_unit_ac.mw

Another possibility is to utilize key assumptions under a change of variables,

Download earlier_integral.mw

[edit] In fact the same well-behaved exact form can be obtained even more directly. (The key here is to also pass the assumption x0>0.)

I wouldn't be surprised if there is a more direct way.

Download solve_id_diff.mw

The above works by changing the diff calls into mere names, so that one of them can be used as the second argument within the identity(...). A variant might be,

solve(identity(subsindets(r=g,specfunc(diff),freeze),
               freeze(indets(r=g,specfunc(diff))[1])),
      [x,y]);

You referred to additional, "complicated" cases. It's often much easier to provide a usefully extensible answer if you provide more than your simplest example.

ps. For that call to solve, you could optionally pass [x,y,T,f,u] instead of just [x,y], etc.

Having all those individual elementwise operations seems overly complicated (and as seen, somewhat error prone), especially in 2D Input mode.

It's also less efficient, I suspect, since using it produces lots of collectible garbage Vectors unnecessarily.

Instead, you could simply construct a single operator that acts on scalars, and then apply that elementwise to your pair of Vectors.

Download Elementwise_ac.mw

note: I would often prefer a scalar operator (used as a single elementise operation) then a whack of visually confusing typeset elementwise operations in 2D Input, even if it were less efficient (and I suspect it sometimes isn't). Opinions may vary...

ps. Here you might also use zip(sm,V2,V1) instead of sm~(V2,V1) .

You can simply declare the name a as local to the procedure, without the type being part of that declaration. You don't have to add types to any local declarations. For example,

   proc(...)
      local a, b;
      a := Array(...);
      b := [...];
    ...
    end proc

The special type declaration of locals is only enforced (when the procedure gets subsequently called) if the assertion-level check is set high enough (which it is not, by default).

For the Description of the Help page for Topic procedure:

By default the value of kernelopts(assertlevel) is 0. So by default such types specified in local declarations are not checked. They can be present, whether checked or not. You have to issue kernelopts(assertlevel=2) to have them get checked when the procedure gets called (run).

The presence of the types in local declarations in your custom procedures is optional. Whether such types are checked is also optional (and can be enabled/disabled by command).

Does that make it clear?