In the very first nested double loop of the worksheet (over i and j), there are assignments to PDE[5][i, j] and other PDE[..] entries.

In the assignment to PDE[5][i, j] there is an instance of chi without indices, in a subexpression like,

    ( chi+(sum(C[1][j, k]*W[i, k], k = 1 .. M))/lambda2 )

This seems like a mistake.

Later on, chi is replaced with a Matrix, so that subexpression seems to not make sense.

If I (guess and) change that to chi[i,j] then a valid system of equations gets passed to fsolve, and a numeric root is found for that system.

test_fsolve_ac.mw

One approach is to construct a Worksheet/Document that looks how you want it (pair of empty input lines, say), save it somewhere, and then make that your custom "start page".

Eg,  From the main menubar, Tools -> Options -> Interface and change the drop-menu item Open worksheet at startup to  Specified worksheet . Make that point at your saved file. Optionally, set that file as read-only in your Operating System, outside of Maple, so that you don't accidentally overwrite it once you start work. That is, always do Edit -> Save As before any Edit -> Save, to save new work to a new file.

You should then always be able to get to this template using the "start page" icon from the menubar, which looks like a house.

Thomas's answer is good and useful.

But, since you asked about sum, it could be noticed that there is a difference in behavior for eval versus limit of the reciprocal of that factorial call. And sum can try to use both.

restart;

eval(1/(n-1)!, n=0);
Error, numeric exception: division by zero

eval(1/GAMMA(n), n=0);
Error, (in GAMMA) numeric exception: division by zero

limit(1/GAMMA(n), n=0);
                               0

limit(1/(n-1)!, n=0);
                               0

So, when n is considered real (as under your sum examples), the limit of the reciprocal comes out as zero (even though the limit from left and right of the factorial call are infinity with opposite signs).

In the following attachment, sum does try to evaluate factorial with argument -1, early on. When that fails it can try limit instead (on the reciprocal expression) and get the 0 result.

factorial_sum_numericvent.mw

Use the stopat and unstopat commands to insert and remove DEBUG() calls within the procedure body.

You can supply an extra argument to the stopat command, to specifiy a line number.

You can see the line numbers by issuing the showstat command, eg. showstat(genpellsolve) .

It's hardly suprising that the debugger isn't being effective in your example, given that the DEBUG() is after all the computations in the genpellsolve procedure except for the return. So the debugger won't intervene until the return line, with the way you've written it.

debugger_basics.mw

Do you mean this?

Download physicsdiff.mw

There are lots of slight variations that can produce this. Here is another below, which happens to not require using op to yank out the first frame of the spacecurve animation.

You could also generate a 3D line-segment using just two end-points, rather than a spacecurve with its default number of data points.

You might be interested to know that the thickness=2 option you had in your second call to animate is eventually affecting most of the structures. It clobbers the thickness=3 you had on the spacecurve, and even affects the plane. This is because you have it as an option to the animate command itself, rather than as one of the arguments to the plotting command (which appear inside the brackets, the second argument passed to animate).

You could also use spacecurve instead of plot3d for the helix, and then pick up the color=red option which you seemed to be wanting(?) there. This also makes a smaller memory footprint. The "size" of animation structures in Maple can often affect GUI, or export, time performance, so I thought you might like to know.

restart;
with(VectorCalculus): with(Student[LinearAlgebra]): with(plots):

v[i] := 145000: thetabn := (1/8)*Pi: thetavn := (1/6)*Pi: k := 10: omegac := .5:
lrange := 6*Pi: v[b] := cos(2*thetabn)/cos(thetabn):
v[g] := sin(2*thetabn)/cos(thetabn): n := `<,>`(k*cos(thetabn), k*sin(thetabn), 0):
vr := [v[b]*t, v[g]*sin(omegac*t)/omegac, v[g]*cos(omegac*t)/omegac]:
lambda := v[i]*cos(thetavn)/cos(thetabn):

pt := [t, 0, v[g]/omegac]:
pline := A -> display(plottools:-line(eval(pt,t=lrange), eval(pt,t=A),
                      thickness = 3)):

shockplot := PlanePlot(n, caption = "",
                       planeoptions = [colour = blue, transparency = .5],
                       normaloptions = [shape = cylindrical_arrow, colour = red]):
t1 := textplot3d([k*cos(thetabn), k*sin(thetabn), 0, 'n'], align = above):
B := animate(pline, [A], A = lrange .. 0, paraminfo = false,
             background = display(shockplot, t1)):
C := animate(spacecurve, [[v[b]*t, v[g]*sin(omegac*t)/omegac,
                           v[g]*cos(omegac*t)/omegac],
                          t = 0 .. x, colour = red, thickness = 2],
             x = 0 .. lrange, paraminfo = false, labels = [" ", zeta, xi],
             background = display(shockplot, t1, pline(0))):

display([B, C], insequence,
        axes=none, orientation=[-158,-17,0], scaling=constrained);

There appear to be infinitely many solutions in the set determined just by {c11=-1. c9,c3=-1.,c5=-1. c7,omega=0} .

So, as long as you make c11, c3, c5, and omega respect that, then you could make the remaining variables take on whatever scalar values you want.

Download solve_ac.mw

Using Maple 18 (like you),

Download ask_ac.mw

It's possible that `evalf/int/control` is not falling back gracefully, after encountering the overflow.

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