It might even be fun(?) to use the URL package to look up the current conversion rate and amend the AUD unit's conversion formula.

Download CURRENCY_AUD.mw

You can left-align each of a sequence of Typesetting:-mtr rows, and then put them inside a call to Typesetting:-mtable .

(This is similar to how Matrices are typeset, but without the braces.)

I haven't bothered to remove your Tsprintf procedure, now unused. And I haven't bothered to make the conditional branches more streamlined (it shouldn't be necessary to make it all explicit like that).

You could also have various different procedures that each returned their own Typesetting:-mtr call (eg. for different kinds of question). You wouldn't be able to print them, until you could wrapped all such results in a single Typesetting:-mtable call.

Download Goi_mapleprime_ac.mw

You can easily generate a sequence of such things.

So, you could use such a generated sequence in the arguments of the Minimize command.

seq(x[i]=1..2, i=1..5);

    x[1] = 1 .. 2, x[2] = 1 .. 2, x[3] = 1 .. 2, x[4] = 1 .. 2, x[5] = 1 .. 2

op(map(v->v=1..2, [W, a, x, y]));

             W = 1 .. 2, a = 1 .. 2, x = 1 .. 2, y = 1 .. 2

expr := a^2+sin(b*Pi+c):

indets(expr, And(name,Non(constant)));

                          {a, b, c}

op(map(v->v=1..2, indets(expr, And(name,Non(constant)))));

               a = 1 .. 2, b = 1 .. 2, c = 1 .. 2

As far as I know it is only possible to specify one light source.

The wording in the documentation might be improved, but I suppose the idea is that it is providing an alternative to the Light1, Light2, etc, stock lighting model choices.

[edited] Sorry, I was in a rush earlier.

I often find it helpful to remember that the results of plotting commands -- plot structures -- are just unevaluated function calls. One can assemble them manually, as well as pick them apart. The stock plotting commands just happen to provide useful functionally for constructing particular plot structures that the GUI renders with some commonly wanted appearances.

There are a few interesting things that can be constructed manually, yet don't have a path to that construction via the stock commands. I don't believe that's the case here.

There are also a few things one can discover.

The PLOT3D function call (structure) can have a MESH substructure as one representation of a surface. The LIGHT function call (substructure) has no effect if it appears as a local plot option within a MESH substructure.

The LIGHT substructure only has an effect as one of the arguments of the outer PLOT3D structure. Sometimes this is referred to as a global plot option, on account of this. And the Standard GUI seems to only utilize the last LIGHT substructure found in the outer PLOT3D structure. In other words, only one lighting source can be specified per PLOT3D structure.

note. One of the important jobs of plots:-display is to sort out what global plot options are present, when passed multiple plot structures, and merge them when possible.

LIGHT_structure.mw

I'm not sure what you want changed.

For your animations, you don't have to put the common plot (common to all frames) in a display call with the other bits. If you use the plots:-animate command then it can look a little tighter, IMO.

Also, if you use a few procedures then you could probably avoid using do-loops that assigned to k, n, etc. And so you might not need to keep unassigning those.

And some plot options like xtickmarks, labels, etc, only need to be supplied to the final display call (or animate).

with(Statistics): with(plots):
ChisquarePDF := unapply(PDF(RandomVariable(ChiSquare(a)),var), [a,var]):
NormalPDF := unapply(PDF(RandomVariable(Normal(mu,sigma)),var), [mu,sigma,var]):

h := algsubs(x = sqrt(2*n)*w + n,sqrt(2*n)*ChisquarePDF(n, x)):
makeN := k -> display(plot(eval(h,n=20*k), w = -3.52 .. 3.52, color=red, thickness=2),
                      textplot([1.8, 0.3, sprintf("n = %a",round(20*k))],
                               font=[TIMES,BOLD,12], color=blue)):
animate(makeN, [k], k=1..15, frames=15, paraminfo=false,
        background = plot(NormalPDF(0, 1, x), x = -3.52 .. 3.52, color = blue, thickness=2),
        title = `pdf of the Sum of Transformed Chi-square(1)\nRandom Variables and the N(0,1) pdf`,
        titlefont=[TIMES,BOLD,12], labels=[``,``],
        xtickmarks=[-3.5+0.5*k$k=0..14], ytickmarks=[0.05*k$k=1..8]);

It would be much better to upload a worksheet with 2D Input, rather than to try and paste that in as plain text.

If your term typed in as 2 k alpha[1] alpha[2]0 is just a typographical mistake, and you intended 2 k alpha[1] alpha[2] instead, then how do you feel about k=0, w=0 ?

solve_sys.mw

For fun, here are a few additional ways to customize plots for this.

You can uncomment some of the options below, for a few more variations.

Download Histogram_varieties.mw

Regarding your Question 2, yes, you can construct procedures that can selectively apply trig formulas according to their argument.

Here is one example of using applyrule to selectively apply a formula.

There are several other ways to accomplish your goal. For example, you could programmatically build some side-relation equations -- using chosen names or arguments -- for use within a call to simplify. Or you could utilize applyrule with a general rule and temporarily freeze the trig calls you want untouched. And most of these approaches could be abstracted further, where one writes procedures which generate the rules, or procedures which generate procedures.

Download targeted_doubleangle.mw

The call rand(1 .. 2) constructs and returns a procedure which can then be called to obtained a (random) number in the given range.

If instead you call rand(1 .. 2)() then the constructed procedure will be called immediately and return an actual number.

But you don't need to call rand each time through the loop. You can call it once, outside the loop, to construct the random number generating procedure. Then, inside the loop, you can call that procedure to get actual numbers.

Download CoinToss_acc.mw

You cannot sensibly assign to xi and xi[0] like that. I suggest using another name instead of xi[0]. The name xi__0 will also prettyrpint as a subscripted name.

restart;
l := -2;
m := 1;
k := sqrt(-1/(6*beta))/l;
w := (1/5)*alpha/(beta*l);
a[2] := -12*sqrt(-1/(6*beta))*alpha*m^2/(5*l*l);
a[0] := 0;
a[1] := 0;
F := -l*C[1]/(m*(C[1]+cosh(l*(xi+xi__0))-sinh(l*(xi+xi__0))));
beta := -2;
alpha := 3;
C[1] := -1/1000;
xi__0 := 1;
xi := k*x-t*w;
u := a[0]+a[1]*F+a[2]*F*F;

plot3d(u, x = -3 .. 3, t = -3 .. 3);

Any fixed image will look pixelated if you zoom in enough. Your example creates a 500-by-500 pixel image, so of course it'll look pixelated with even a moderate amount of zoom, if embedded at the same resolution.

You can either increase the resolution of the image (you had it as 500-by-500), or you can dynamically recreate the image as you zoom in.

Eg, (with all the calls in separete Execution Groups or Document Blocks!)

restart;
# Compare these next two results.
# You can chop, crop, and then rescale the one with higher resolution,
# to get the effect of zooming.

ImageTools:-Embed(Fractals:-EscapeTime:-Julia(900,
                                     -0.01*(1.0+I)+(-1.7-1.7*I),
                                     0.01*(1.0+I)+(1.7+1.7*I),
                                     -0.8 + 0.16*I,
                                     iterationlimit=70, output=layer1)):

ImageTools:-Embed(Fractals:-EscapeTime:-Julia(500,
                                     -0.01*(1.0+I)+(-1.7-1.7*I),
                                     0.01*(1.0+I)+(1.7+1.7*I),
                                     -0.8 + 0.16*I,
                                     iterationlimit=70, output=layer1)):


restart;
# Or you can regenerate and redisplay, to the modest size, as you zoom.

Explore( Fractals:-EscapeTime:-Julia(500,
                                     -0.01*(3.0+I)+(-2.0-2.0*I)/exp(zoom),
                                     0.01*(3.0+I)+(2.0+2.0*I)/exp(zoom),
                                     -0.8 + 0.16*I,
                                     iterationlimit=70, output=layer1)
         , parameters=[ zoom=0.0..4.0 ]
         , size=[500,500]
         , animate
         , placement=left );

julia_zoom.mw

Another alternative is to create a high resolution image just once, and then Explore the fixed smaller resolution (say, 500-by-500) effect of using ImageTools:-Scale to chop and scale that original, thus zooming in. That would also let you pan around. And most of the computational time would be "up front". Here's an example of that with a 6000-by-6000 starting image. (Reduce that initial size, if it uses too much memory for you.) As you can see, no matter how high the resolution of the original, eventually zooming in far enough to a fixed image willl result in a pixelated look. Hence my preference for the former scheme above, where the computation is re-done for every "zoomed" range.

restart;

N := 6000;

# This first computation takes some time. (7sec for me, but YMMV)
raw := Fractals:-EscapeTime:-Julia(N,
                                   -0.01*(1.0+I)+(-1.7-1.7*I),
                                   0.01*(1.0+I)+(1.7+1.7*I),
                                   -0.8 + 0.16*I,
                                   iterationlimit=70, output=layer1):

Z:=proc(N,cv,ch,s)
   uses ImageTools;
   if not [cv,ch]::list(posint) then
     return 'procname'(args);
   end if;
   Scale(raw[ceil(cv-(N/2-s)/2)..floor(cv+(N/2-s)/2),
             ceil(ch-(N/2-s)/2)..floor(ch+(N/2-s)/2)],
             1..500,1..500);
end proc:

Explore(Z(N, cv, ch, s),
        cv=N/4..3*N/4, ch=N/4..3*N/4, s=0..N/2,
        initialvalues=[cv=N/2, ch=N/2]);

image_zoom.mw

If your whole computation is intended to deal with floating-point arithmetic (like your example) then you can improve performance by using either evalhf or Compile, as shown below.

You have unwisely chosen to show us only a portion of your complete work. It's is possibly that other parts of your complete work will not run directly under evalhf or Compile. But in that case you could still split off the portions which do from those which do not. Help cannot be given for the parts you do not reveal to us.

You mentioned memory issues, and name the figure 4Gb, for your complete work. It's not clear at all whether that refers to bytes used or bytes allocated. It's also unclear whether you're main difficulty is in how long the computation takes, or whether the whole problem requires excessive allocation of memory.

Download procedure_new_ac.mw

[edited] I've put my earlier Answer's commentary, into this attached copy of my earlier worksheet. That took about 7 minutes to find a point that attained about 1e-3 as largest equation residual of the problem cast as a global optimization problem. It turned out that minimum point could be used by fsolve to quickly find an actual root. kompletter_nachbau_v0_acer_fsolve_commented.mw

The methodology includes eliminating h[0] by equating the rhs's of two pairs from the three equations containing that that variable (after isolating for it). The variable p was treated specially, and bounds supplied for all remaining variables.

Later, it occurred to me that fsolve could be attempted for every p value attempted, following the inner DirectSearch:-SolveEquations step. I then discovered that the first p value tried was succeeding, for a variety of fixed p values within some bounds. This cut the total computation time down from about 7 minutes to about 7 seconds. And it allows finding multiple distinct roots. kompletter_nachbau_v0_acer_fsolve_3.mw

Then it occurred to me that perhaps having a starting point (for fsolve) that was close to globally optimal in the (sum of squares of residuals) optimization problem might not be necessary for fsolve to succeed in finding an actual root. So here is a revision where SolveEquations provides a feasible (all equations real-valued) starting point for fsolve, where that point may not be particularly close to optimal. The evaluationlimit option is passed to SolveEquations with a relatively small value of 1000. And this subsequently produces an actual root from fsolve. And there are no ranges supplied for any of the variables. And the whole thing takes 1.5 seconds on a fast machine.

(I've put the equations into the Startup Code region, so they don't take up space here.)
Download kompletter_nachbau_v0_DS_fsolve.mw

Firstly, you need to upload an actual Worksheet or Document, if you want us to be able to see precisely what you have. Use the big green arrow in the Mapleprimes editor pane, to upload and attach.

You need to fix your brackets, which don't always match in several of your examples.

Eg. the call to the eval command in your second proc has mismatched round brackets. It's missing the closing bracket.

And in one of your calls to the procedure you have mismatched square brackets.

There are other syntax problems, some possibly related to attempts at getting implicit multiplication. But it's impossible to be sure without an actual upload.

If 2D Input in a Document is too much trouble for you, you can change the preference to be 1D plaintext Maple notation in  Worksheet. (I suggest this, for new users.)

eq := a*b=a*c;

                        eq := a b = a c

gcd(rhs(eq), lhs(eq))

                               a

map(`/`, eq, gcd(rhs(eq), lhs(eq)));

                             b = c