You might use the orientation 3D plotting option.

For example,

Download tareaclase6_ac.mw

An imported image (as float[8] Array) can be used for the coloring in a density-plot structure.

Once appropriately scaled, this can be translated to arbitrary x-y positions.

The following code could be made more efficient (and easy, with a re-usable procedure to scale/translate/etc). But I'd like to know whether it will suffice, before making the effort.

Naturally one can change the Read line below, to instead use some other external image file. (The OP didn't provide an image file.) All the code below needs is the usefully scaled (70x70x3 works ok) Array assigned to img.

Download image_plot.mw

I suspect that the GUI will be generally less sluggish using such density-plots than it would with, say, colored point-plot assemblies.

That density-plot structure could actually be formed via the plots:-densityplot command, using the Array from the image. I simply found it easier to form it directly, as above.

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.