You mentioned at one point that you prefered not so use uneval-quoted 'sum'(...) for the inner summation because then you wouldn't get the summation symbol. I suppose that you might feel similarly about using a nested call to add.

It seems that for this example another workaround variant is to use inert Sum for the inner summation. That typesets with a  summation symbol, albeit in gray.

In 1D Maple Notation that could look like this.

X := [0, 1, 2, 3]:
n := 2:
value( sum(Sum(a[k]*X[i]^k, i = 1 .. nops(X)), k = 0 .. n) );

                           4 a[0] + 6 a[1] + 14 a[2]

In 2D Input it could look as follows. Note that I used command-completion (Ctrl-Shift-Spacebar on my Linux) after typing the word Sum and chose the command "template" for inert definite summation from the popup menu offerings.

I also keystrokes Ctl-Shift-underscore in my Maple to get the subscripted display of X[i] and a[k]. You could also just enter X[i] and a[k] to be displayed as indexed names, if you prefer. In earlier version of Maple getting 2D Input for an indexed name involved a different set of keystrokes.

Download typesetsum.mw

You also wondered why you couldn't place uneval-quotes around the entire inner summation, when using sum. For this example it seems that you can, if you handle nops(X) slightly differently. (The nops(X) looks ugly as upper index value on the summation symbol, anyway, in my opinion.) I used Maple 18.01 here too. In 1D Maple Notation,

X := [0, 1, 2, 3]:
n := 2:
r := nops(X):
eval( sum('sum(a[k]*X[i]^k, i = 1 .. r)', k = 0 .. n) );

                           4 a[0] + 6 a[1] + 14 a[2]

And in 2D Input using command-completions (or palette for typeset definite sum) the following has both summation symbols in black. Of course the uneval-quotes detract somewhat.

Download typesetsum2.mw

acer

Download solvegrin2.mw

acer

In Maple 18 a new 2D plot option size was introduced. This can be used with the 2D plot command and with 2D commands in the plots package, and when using the plots:-display command on 2D plots.

In Maple 17 the Standard Java GUI already understood an earlier form of the relavent substructure (or a PLOT structure) related to sizing. But the usual documented 2D plotting commands mentioned above did not have any means of inserting this substructure. But it could still be accomplished in Maple 17 (for just the choice of posint pixel numbers width-by-height) using the undocumented Plot:-Structure:-SetSize command.

And there are limitations. The result below of calling SetSize cannot subsequently be combined with other 2D plots or otherwise generally adjusted using the plots:-display command. You'd have to first do all the combining, and then make the call to SetSize be the very last action before finally doing a simple print call on the resized PLOT structure.

Also, I don't think that the File>Print mechanism of the Maple 17's GUI's menubar understands the structure. But pdf Export might...

Download m17setsize.mw

In Maple 18 one should definitely not go this route. Use the documented size option instead.

acer

The Grid package would provide more insulation.

acer

Put the procedures and computed results into a Library archive (.mla extension).

Build that, and put things into it, and extract from it, using the LibraryTools package.

acer

In a followup Comment to Carl's Answer you asked about minimal and maximal angles which would attain the right-center field home run, given the two initial velocities as mentioned in your original Question.

Download bballfull.mw

Sorry about the gridlines in that plot, they are an unfortunate artefact of the MapleNet server currently used by MaplePrimes. They don't appear in the attachment.

acer

As far as I know Maple doesn't have a prebuilt mechanism by which general computation can be done via the GPU.

Do you have some reason to think that it does?

acer

Download LaguerreL_ident.mw

acer

There have been several reports of the same error message, specific to Maple 18 (or an update of same). It seems that a reinstall usually fixes the problem.

I don't know whether the problem is with corruption of the installer when it's downloaded (in which case you'll have to download again), or whether the problem is at the installation step from a viable download (in which case you just need to retry with the same installer).

acer

It's a bit of a chore, but one of the identities that FunctionAdvisor reports for LegendreP seems to be useful. I extracted that and assigned it as identityA below.

Also, to convert back from LegendreP to SphericalY I had to invert the reverse conversion, which I assigned as identityB below.

It's possible that there is a relation similar to identityA which could be applied to the expression while still in SphericalY form. And that might remove the need for identityB. But the SphericalY form seems to need even more combinations of simplification steps.

Not all the simplify(...,size) calls wrapped around simplify calls may be necessary, but it keeps some of the intermediate expressions a little tighter and easier to understand I think.

I ran this on Maple 18.01.

restart:

with(VectorCalculus):
SetCoordinates(spherical[r,theta,phi]):

# Originally I used these assumptions for all simplification steps.
# But it seems as if they are not needed...
#conds := lambda::posint, mu::integer, abs(mu)<=lambda:

ee := Laplacian(SphericalY(lambda,mu,theta,phi)):

identityA := subs(a=lambda+2,b=mu,z=cos(theta),
                  convert(FunctionAdvisor(LegendreP,"identities",quiet)[6],`global`)):

identityB := isolate(SphericalY(lambda,mu,theta,phi)
                       = convert(SphericalY(lambda,mu,theta,phi),LegendreP),
                     LegendreP(lambda,mu,cos(theta))):

combine(simplify(simplify(convert(ee,LegendreP)),size),radical):
simplify(simplify(%),size):

simplify(simplify(subs(identityA,%),size)):

normal(simplify(subs(identityB,%)));

            lambda (lambda + 1) SphericalY(lambda, mu, theta, phi)
          - ------------------------------------------------------
                                       2                          
                                      r                                            

acer

pairs := convert(M,listlist);

acer

Two instances of an adjacent pair of bracketed terms are being interpreted as function application, so if you intended them as products then you left out two instances of multiplcation syntax.

The simplest thing, in that case, would be to insert a pair of multiplication symbols.

solve({(1-x)/(1+b) = b*y, (1-y)*(1-a)/(-a*b+1) = b*z, (1-z)*(1-b)/(-a*b+1) = a*x}, {x, y, z});

acer

If the problem is that the grid shown on the rendered surface is too dark in your Maple 13 then how about using one of these option choices for your call to plots:-display?

style = patchnogrid

or

style = wireframeopaque

acer

There are three kinds of problems that I see here.

The first problem is that you have a typo. It is Explore, not EXplore.

The second problem is that your document appears to be using the indexed names I[b] and I[c] to get the subscripted 2D Math.

Both the Explore and the plot commands may have a problem with that. You'd be better off using so-called atomic identifiers (unique names) for those, instead of the indexed names.

In the attached worksheet I've made a replacement right at the end. I used Maple 18, in which in 2D Input I typed the input for the atomic identifiers as I__b (which is I underscore underscore b as the keystrokes). Alternatively you could use atomic identifiers instead of indexed names throughout your whole document (I didn't change the whole thing). If you have an older version than Maple 18 you can still use atomic identifiers but the mechanism for entering them is different. Of course you could also use simple names like Ib and Ic but I'm guessing that the subscripting is important to you. Note that the slider in the exploration might not get its label typeset as 2D Math.

The third problem is that Explore doesn't figure out the underlying names in M[ba] , which has been assigned the expression to be plotted. That's because of special evaluation rules that Explore has on its first argument. One way around this, which I did in the sheet I attach below and which is similar to cases in ?examples,Explore , is to use a simple procedure.

shiboft2_edited.mw

 acer

At Digits<=15 Maple can use double precision (64bit) hardware floats and store Matrices of real or complex floating-point values in contiguous blocks of memory. That's what is called a datatype=float[8] rtable in Maple. And linear algebra computations such as eigenvectors, matrix-matrix products, etc, are then done in specialized compiled libraries such as the Intel Math Kernel Library (MKL). Such optimized versions of standard libraries of functions such as LAPACK and the BLAS are cache-tuned and often make use of chipset extensions such as SIMD and AVX or are otherwise parallelized.

At Digits>15 Maple uses a so-called "software float" representation where such high precision floating-point values are stored internally using big integers. Basic arithmetic can then use GMP et al. But this is much more involved than using optimized or vectorized arithmetic functions built right into the CPU hardware. Linear algebra computations done with such software floats in Maple is accomplished using generic nonparallelized BLAS and LAPACK libraries recompiled to redefine "double" and overload arithmetic with hooks into Maple's kernel.

Yes, the jump in timing is quite steep, at the crossover from hardware to software precision.

It might be possible to soften the blow of the crossover a little, by having a quadruple-precision implementation of the BLAS and LAPACK, to cover a range close to Digits=16 through Digits=30 or so. Or perhaps key generic software float BLAS functions could be parallelized or cache-tuned.

acer