@Axel Vogt 

restart;
kernelopts(version);

      Maple 2018.2, X86 64 LINUX, Nov 16 2018, Build ID 1362973

g:=exp(r*cos(theta))/Pi+exp(r*cos(theta))*cos(theta)/Pi:
Int(g, theta = 0 .. Pi):
value(IntegrationTools:-Expand(%)) assuming r>0;

         BesselI(0, r) + BesselI(1, r)

# Or,

int(g, theta = 0 .. Pi):

IntegrationTools:-Expand(%) assuming r>0;

         BesselI(0, r) + BesselI(1, r)

The two separate integrals are obtained by method=lookup, but that is not being successfully used against the sum.

Could you not utilize the assuming mechanism for the key simplifications?

Show us what youve been able to do so far with this homework question.

@zphaze I'll look into this, as well as another kind of evalf-related bug in it that I know of.

Perhaps you're also the fellow who asked about saving the module to an archive. There are a few subtleties (including ModuleLoad material), but nothing not easily resolved.

If you give me a couple of days (it's Sunday night...) I'll look into these bug/issues which I expect are easily resolved, as well as show/verify both the module saving as well as cloud-package creation. I've been meaning to do all that for some time now.

I will post in this thread, when progress is made.

Show us how far you've gotten already with this homework. 

What does it mean, pasting in a polynomial from Mathematica to Maple? How does that statement make sense, without context? You haven't even said in what format or syntax that would act.

Also, are you trying to paste in 10k term expressions into Maple in 2D Input mode? That sounds dubious at best.

Why not write out a poynomial in plaintext form to a text file from Mma, and then read it into Maple?

@kfli The `.` command already goes straight through the kernel to the MKL BLAS dgemm and I doubt that you'd be able to beat that for most large sizes.

I say "most large sizes" because your goal is still very unclear, in terms of what I'd consider necessary in order to arrive at an efficient solution without runaround guesswork.

You haven't stated that your Matrices/Arrays are float[8], but I suspect that they are. You haven't stated whether you need a modest number of very large examples to run fast, or a very large number of small examples to run fast (by avoiding overhead). You haven't stated whether you want to be able to do this kind of inplace BLAS operation (possibly with the actual transposition being avoided):
    C <-  A . B  + C   or    C <-  alpha.A^%T . B^%T + beta*C
etc. If you really need such cases (ie. inplace action on C to avoid garbage collection, without overhead) then please describe the scenarios in fine detail.

It would be much better if your clearly explained your broader goal, rather than showing us difficulties you have with your attempts at getting there.

@vv 

Download rsolve_goofy.mw

@mmcdara Yes, the double underscore is just to avoid collision with other names (including special ones).

Another way to do such things is to use an anonymous procedure which is called directly. In such a way name collision is avoided, as the temporary names are local. For example, the following is procedure call of an anonymous procedure. Note the round brackets at the end.

   proc() local LL,KK,KO,NN,ver; ....etc... end proc():

@opus64 Right, that is why I stated that, "the optimal solution would be for each parameter's label in each separate exploration to be able to retain its own independent formatting specification."

By the above I meant a scenario in which each parameter could get its own individual treatment, and in which that individual treatment would be part of the embedded exploration's (handling of the) individual Slider components (and not the package's general common runtime).

At present there is no way to get distinct formatting for distinct parameters (eg, with values on quite different scales).

@mmcdara Thank you. However, your claim is not true, in several ways.

For regular output, the following can be done (since about Maple 18 or whenever 2D plots got the size option):

Resize:=proc(P,m::posint,n::posint)
      op(0,P)(op(P),ROOT(BOUNDS_X(0),BOUNDS_Y(0),
                   BOUNDS_WIDTH(n),BOUNDS_HEIGHT(m)));
   end proc:

P:=plot3d(cos(x)*y^3,x=-Pi..Pi,y=-1..1):

Resize(P,700,700);

The difference is that the code in the Post (at top) enables the size option to be used directly in each plotting command. That's more direct than modifying a generated 3D plot result, after generation, with such a Resize procedure. That is the central idea of this current post.

Since you mention DocumentTools, well, there too it is possible to embed a plot that is either smaller or larger than default. Your code snippet is just not one of the ways to enlarge it. The DocumentTools facilities also allow for embedding of programmatically scaled and panned plots. But note that these DocumentTools mechanisms are only for embedded display effects, whereas the size option produces a plot as output/return-value and which carries its size details as part of its structure. 

Upload a .mw Document/Worksheet that reproduces your problem in full.

You can make it at attachment here  using the green up-arrow in the mapleprimes editor.

@mmcdara In this attachment (made with Maple 2015), it does what you've shown except for showing one step separately.

That omitted single step is the bringing of the inert Diff inside the inert Sum, prior to actually differentiating. It could be done, but perhaps not in a way that makes the mechanism natural for any non-Maple-user audience.

The loading of student is to get the Sum expansion in Maple 2015. The extended typesetting mode is to allow inert `%.` to prettyprint nicely, since not default in Maple 2015.

Download SimplifySum_bis_ac.mw

@vv Thank you very much for the comments.

I believe that the failure to auto-scale (to a square the size of the smaller dimension) for the case you mention is fixable. I have also observed somewhat new behavior when manually resizing purely horizontally, on occasion, and I've reported that regression recently. But the case of a purely square window, or oblong in the other orientation, seems fine..

I also believe that the case you describe is quite uncommon, since if behaving fixed it would incur the wasteful white space above and below (which is unpopular). Or one could simply force a large square. So, either undesirable or already attainable.

I would also like new plot substructures to denote the axis ratios, and the pan and zoom. The latter pair of those are currently stored in the XML of a .mw file but not in the actual plot structure; ie. Maple language. So some of those effects can be achieved by embedding with DocumentTools, but not with regular output. There is an example of an animation within a long prism in the Help, where the 3D plot shows without the usual unfortunate large white spaces above and below.

Small steps...