There is no such options as size for 3D plotting commands, and hence it is not accepted by the plots:-setoptions3d command.

However, the ROOT substructure which is used for 2D plots can in fact be inserted into a PLOT3D structure, and the GUI will repsect it.

Below is a command which will insert such a ROOT substructure into a PLOT3D structure, and resize it.

Since the Library commands don't expect to encounter such a substructure within a PLOT3D structure, you may need to ensure that this is the last operation done prior to displaying the plot. Eg, you may wish to apply it only after combining multiple plots using plots:-display, or applying plottools:-transform and friends to the original 3D plot.

You can always remove such a substructure with subsindets, since that substructure is a ROOT function call.

Note that the ROOT substructure modifies the plotting window's size, but does not rescale or zoom the plot. The routine I've provided allows width and height to be different, but in practice you'll find that only square dimensions (ie, m=n) produces something useful.

This functionality to specify the size of 3D plots has been on my wishlist for quite a while now. But I feel that a true solution would also consist of functionality to set the scaling factor (zoom) as well as custom aspect ratios for constrained 3D plots (which would need entirely new items allowed in the PLOT3D sustructure). For 2D plots all that is naturally obtained by just the dimensions, but for 3D plots all those features are related but distinct.

Download SetSize3D.mw

Sometimes it is convenient to pass multiple arguments via one or more Arrays (or Vectors), if you are going to be calling it several times, with manual typing.

This can make calling the procedure shorter to type, and less work if only a few entries get changed between calls. Eg,

Params[45] := newvalue:
Params[46] := anothervalue:
Func( Params );

Of course it's becomes necessary to document adequately the role of each Array entry. Stay organized, as that will pay off.

And you can use a few such Array parameters, separating them in various ways: by type (integers vs floats vs others), or by purpose. You can also have some additional parameters still be passed as scalar, or via positional or keyword options.

This approach can become awkward if you want to program a sequence of calls to the procedure, and one of the Array entries is varying.

You mentioned that your worksheet has 100 or more parameters. I would not be surprised if there would be benefits to doing the computations using several procedures, and those might not all require all the parameters to be passed. A reasonable amount of focus on an effective design of the computational flow usually pays off.

The background option for 2D plots was introduced in Maple 18.

So if really do have Maple 16 (and not Maple 2016, which later) then one way to get a curve plotted over an image involves first turning the image into a densityplot.

You didn't say whether you wanted to re-scale the sine curve, vertically, if the image was not in the same proportions as the x- and y-ranges. Or vice versa. So I chose the former. And it wasn't clear whether you wanted to display axes, whose tickmarks might match the sine values and x-y data.

Download background_maple16.mw

Look inside the Startup Code Region of this first attachment.  From the main menubar choose items Edit -> Startup Code (Ctrl-Shift-E).

MaplePlayerSlideShowTest_ac.mw

Alternatively, you could make the calls to DocumentTools:-SetProperty be full and explicit, in the action code of the Buttons. And you could also form their action strings with Plot1 explicitly replacing id. In this next attachment there is no need for Startup Code.

MaplePlayerSlideShowTest_ac_2.mw

You forgot to give numeric values for A and `ϑ` .

Are you trying to get y-values for the curves at a common set of sigma values?

That is possible for the upper four curves, since they start (or finish) at the same value of sigma.

It's not clear what meaning it would have to conjoin the lower curves, since they start at different values of sigma. Please explain what you hope to represent by the 1001x4 Matrix, for those lower curves.

fig10_ac.mw

f := (x, y) -> sin(x)*cos(y):

plot3d(f, -Pi .. Pi, -2*Pi .. 2*Pi,
       style = surfacecontour,
       labels = ["x","y","f"]);

Or, with your own custom choice of contour values (heights),

plot3d(f, -Pi .. Pi, -2*Pi .. 2*Pi,
       style = surfacecontour,
       contours = [-0.5, 0.0, 0.5]);

I consider setting UseHardwareFloats to true as a top-level initialization to be highly dubious.

The default setting is deduced, which means that if Digits<=15 then most Library procedures which take into account such things will already treat deduced like true. You're not getting a whole whack more computations being done with hardware floats with true than you would with deduced, provided that Digits<=15.

Setting it to true will prevent some procedures from working with higher precision software floats, even when they decide either that they should or that they need to for correctness.

If you want scalar floats to be HFloats for some computations, or to always be HFloats when pulled out of datatype=float[8] rtables, then restrict the forced UseHardwareFloats setting to within a procedure (as Joe mentioned, environment variables don't affect the higher scope, by design). Or put option hfloat on such procedures.

If the only big effect of setting UseHardwareFloats:=true was to speed up calculations by doing it all in hardware double precision then it would be Maplesoft's default. But it's not. That setting hobbles the system, understandably IMO.

Download dde.mw

r := 1.9;
                            r := 1.9
i := trunc(r);
                             i := 1

First of all, you don't tell us anything about the qualitative nature of the plot you are expecting, or what specifically you object to above the plot originally produced. (The thing you wrote about "two arguments" makes no literal sense.)

We can of course guess that you object to the sign flip between the discontinuities. But tell us precisely.

Next, while it may not be the cause of your issues, it looks like a really bad idea to apply evalf all over the place, and have those float exponents. Do you understand that when there are branch-cut issues -- around say rational multiples of Pi -- turning exact values into floating-point representations can be trouble. If the float rounds just above..., or just below..., the behavior can change.

So, I am guessing that the combine(zeta_c, symbolic) might resolve your issue. (But, really, you're the one who supplied the various exp calls in the first place, without explanation or source...)

Here's one version with floats, and one without. Is this the plot you expected? Or perhaps as likely, its negation?

Toya_complexPlot2_ac.mw

Toya_complexPlot2_ac_exact.mw

I no longer believe in coincidences.

Working on another question here -- right now -- I stumbled across the same phenomenon.

The problem is the gridlines option, which your .mapleinit sets to true in a call to plots:-setoptions.

If I include that gridlines setting, then the GUI goes bonkers in the way described when I try to use plottools:-transform to raise a 2D plot up to 3D. (I have to use the menubar's Edit->Remove Output From Worksheet, then Save As another filename, then File->Close, then re-open, etc, to recover.

But if I exclude that setting then it goes OK.

I found this out, on the side, because I now habitually use plots:-setoptions to set gridlines=false so that the ancient Mapleprimes backend MapleNet engine doesn't render my inlined worksheet's 2D plots with ugly gridlines.

And then when I tried to transform a 2D plot to 3D I saw the same GUI crash, in Maple 2018.1 on 64bit Linux.

One might guess that setting gridlines=false wouldn't do anything concrete, since the default in the Maple GUI is not to show gridlines when no option for it is supplied. But in recent versions of Maple it actually puts a _GRIDLINES substructure within the PLOT structure of a 2D plot.

Anyway, the problem seems to happen whether the 2D plot is constructed with gridlines=true or gridlines=false.

Anyway, either the plottools:-transform command doesn't handle the GRIDLINES substructure properly when converting from PLOT to PLOT3D, or the GUI is mis-handling what it gets. Probably the former, where plottools is now failing to strip it out, since 3D plots don't really support gridlines. I will submit a bug report.

If you wish to retain your use of the gridlines option within the setoptions call, you could work around the issue by stripping out the _GRIDLINES structure.

Download display3d_subs.mw

Try the command ListDirectory from the FileTools package.

Your main problem was that you were calling your procedure UP with GAMMA as the argument instead of the typeset GAMMA-with-an-overbar.

In order to use Grid:-Seq here you also need to tell the kernel to pass along the definitions of `index/xxx` and RrProc. For that you can use the Grid:-Set command. And also, pass Rr into UP.

I changed the unprotect(GAMMA) to local GAMMA as a top-level declaration. You don't anything like that for the typeset GAMMA-with-an-overbar.

Now the Grid:-Seq runs twice as fast as seq on the two UP calls, on my quad-core 64bit Linux machine under Maple 2017.2. I change M=5 to M=12, to make it take a little longer.

What matters is the real time, which is wall-clock time.

[edited] If I set M=100 to make it long enough to examine the timings better, it takes 33sec with Grid:-Seq and 66sec with serial seq. And the answers are the same. Under serial seq my Linux machine's load showed at 100% (one mserver process), while under Grid:-seq it showed at 200% (across two mserver processes). 

[edited] Your mileage here may vary with OS and Maple version, but this exercise leaves my OS running multiple defunct or orphaned mserver processes (taking no load, phew!), even when the GUI is completely quit. I have to kill them manually.

Download soal_ac.mw

The problem is that you are trying to use GAMMA as if it were a previously unused name. But it is already the name of a procedure in Maple itself.

Trying to unprotect the name, so as to try and use it like a regular, unassigned name, is something you should NOT do.

The error message is telling you what to do. Replace the call to unprotect(GAMMA) with,

local GAMMA;

Or use another name. That might be advisable, if it's supposed to be passed off via Grid.