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. 

Why not solve for t, symbolically, up front? You can utilize that formula directly within the plot command. (There's no need to produce discrete data, although you can if you want.)

Download form_plotting.mw

You can automate parallel (concurrent) computations by using either the Grid or Threads packages. That would be considerably superior to using separate worksheets to cobble together your own parallel computation environment.

As a very rough but general rule: if you can parallelize the job at a fine level (usually for something which is purely numeric and thus more readily made thread-safe) then the Threads package is more suitable, while if your overall goal is more easily parallelized into larger and more computationally expensive (usually fewer, higher level) jobs then the Grid package is more suitable.

With the Threads package the concurrent computations take place under the same kernel session, hence the need for them to not interact with each other (an aspect of the needed thread-safety). Most of the Maple Library's commands are not thread-safe, hence the common occurrence that thread-safe code is mostly numeric or mostly uses kernel builins.

With the Grid package there is greater overhead for launching the concurrent sub-computations, but that is relatively negligible if the sub-computations are more expensive and there are less of them. With this package the sub-computations run in separate kernels, and so are protected from interfering with each other, and the issue of thread-safety is mitigated.

See the Help, or search this site, for examples.

It sounds to me as if the Grid package might be more suitable for your job.

Download loop_print.mw

Here it is with everything but the last plot's output:

triangle_analysis_ac1.mw

Another thing that worked for me was to File->Open the original, and then (even though it appears to have not loaded and sheet appears blank!) use the menubar's Edit->Remove Output->From Worksheet , and then save it to another filename. That produces a version with all output removed.  triangle_analysis_gone.mw