Some of the expressions in list S contain the name u[10]. That is, they are polynomials with u[10] appearing a name and not a function call.

But you previously made the assignment

u[10]:=unapply(1,x):

Thus the call to fsolve does not make sense.

Did you intend to unassign the name 'u[10]' right before calling fsolve (which could result in a solution where u[10] were not 1, eg. u[10] = -.5220762901)?

Or did you intend on substituting the value of 1 for u[10] in S, and passing fsolve one less expression (eg, by removing, say, one of those containing u[10])?

It's not really clear what your general term is, from your description.

I have guessed a general term, where the summation can be done to produce an explicit closed form (last example below). But even when the terms have to be added individually I don't see it as taking "a long time".

Download evalfInt_example.mw

It is pretty fast also with Digits=15 (and reduced accuracy requested for plotting, since you cannot see the difference).

Perhaps you could provide an actual worksheet that illustrates the slow behavior.

evalfInt_example_15.mw

You incorrectly have square brackets around the first argument passed to NonlinearFit, which is not valid syntax. I got rid of them in the procedure k__plot .

Also, I suspect that the very large coefficient in the exp terms is unnecessary and serves only to make it harder for an optimizer (because the corresponding factor k is then needlessly small, with loss of working precision).

Download Nonlinear_Fit_Complex_Equation_acc.mw

restart;

f := (z, n) -> (1-z)^(n-1/2)/(z^(1/2)*Beta(0.5, 0.5+n)):

nJ := (p,c,hi) -> fsolve(n -> Int(unapply(f(z,n),z), 0..p) - c, 0..hi):

ans := nJ(10^(-5), 0.95, 10^6);

                                          5
                     ans := 1.920717307 10 

evalf(Int( unapply(f(z,ans),z), 0..10^(-5) ));

                          0.9499999999

Another way, using the symbolic integration result, and fsolve with a finite range as option.

Download fsolve_example.mw

And, slightly simpler and more robust,

Download RF_example.mw

Here are a few choices of format involving RealRange, if you don't just want to get the easy representation of {b<>2} by calling solve(det<>0) .

Download solve_example.mw

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 `&vartheta;` .

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