ee,ff,gg,hh := 22*Pi/3, Pi/2, -22*Pi/3, -Pi/2;

                     22 Pi   Pi     22 Pi     Pi
   ee, ff, gg, hh := -----, ----, - -----, - ----
                       3     2        3       2

trunc(ee/Pi), trunc(ff/Pi), trunc(gg/Pi), trunc(hh/Pi);

                     7, 0, -7, 0

frac(ee/Pi), frac(ff/Pi), frac(gg/Pi), frac(hh/Pi);

                1/3, 1/2, -1/3, -1/2

If you pass a list of two imported images to the ImageTools:-Embed command then it should embed them side by side in a GUI Table.

Anther choice would be to make them both subimages of an otherwise purely white (or black, etc) image.

When you write that they were created in another program I take it that you mean you have a pair of image files produced by that other program.

When you talk of creating the plots in Maple do you mean doing all the computation, or simply importing the underlying numeric data?

For what general interest it might have, here is an example of taking two previously constructed animations (with the same number of frames) and merging them into a single animation of so-called array-plots.

I used Maple 2019.0 for this. It's possible that it'd function differently in another version.

Download merged_anim_2019.0.mw

Adjustments could be made to the seq generation, to accomodate the case that the two animations had a differering number of frames.

It seems that it's possible to right-click export the above an obtain a single animated GIF file that shows both plots.

[edit] I think I might recall now how/why this works, and so I've deleted some of my earlier commentary. IIRC there is some code inside plots:-display which can "merge" multiple 2D plots in an array-plot by stuffing them into a single PLOT structure (by translating them horizontally and faking the tickmarks). I doubt works for 3D plots. So in this example each frame is one of these things. That'd also explain why it can export them both to a single animated GIF. I'll note that it gives the effect of allowing the (apparent) separate animations to show with a dynamic "view", as opposed to the view being global across frames. I suspect that more truly global qualities like gridlines cannot be different for the "separate" plot things here. [/edit]

Note the syntax := rather than just = for the assignment to sys.

sys := {1800*40+15*(300*30)-30*Biy = 0, -1800+Biy+Ciy-300*30 = 0};

   sys := {207000 - 30 Biy = 0, -10800 + Biy + Ciy = 0}

ans := fsolve(sys);

          ans := {Biy = 6900., Ciy = 3900.}

eval(Biy, ans);

                   6900.

If you use equals rather than colon-equals then you're just creating an equation and not performing an assignment.

restart;

sys = {1800*40+15*(300*30)-30*Biy = 0, -1800+Biy+Ciy-300*30 = 0};

   sys = {207000 - 30 Biy = 0, -10800 + Biy + Ciy = 0}

sys; # was not assigned
                   sys

There are several aspects to improving performance here.

One aspect is the Maple level overhead that occurs before the external call to the compiled cuhre library. Another aspect is the what optimizations can be gained by parallelization.

It's often a good idea to make sure that the serial version runs as fast as possible before trying to paralellize.

Let's consider Library-level overhead first.
 - Don't load all of Student:-MultivariableCalculus. If you need one of its exported commands (and it appears that you don't) then call by its explicit long-form name.
 - Ensure that the integrand is evalhf'able (yours was, so good).
 - Use the operator form calling sequence, rather than expression form, for the integrand. (That saves Maple from having to figure out just how to call `makeproc`.)

I am not sure that the usual entry-points of evalf(Int(...) or int(...,numeric) are thread-safe at the Library level, even when using operator form. At least once I got a seg-fault from the external routine, which I suspect is because the threads were mashing data at the Library level (but I'm not 100% sure why).

If I get time I may look at what overhead could be avoided by calling `evalf/int/MultipleInt`:-cuhre directly with operator form integrand, or possibly even duplicate its methodology. I suspect that Library-level overhead is a measurable portion even for the best timing I show below.

As far as parallelization goes, there is still the distinction between the timing cost of the external code and the preliminary Library-level lead-up the external call.
 - The call_external to the cuhre library may be thread-blocking (I haven't checked yet) and if so then there may also be even greater parallelization benefit in toggling that off (presuming it's thread-safe).
 - There are some small float[8] Arrays that get created each time, and it's plausible that making them be thread-local to a rewritten module implementation of `evalf/int/MultipleInt`:-cuhre could allow them to be be re-used and save on memory management overhead.
 - For this kind of work I'm often only satisfied when I see the amount of garbage collection ("memory used") get very small. At N=30000 it is still 500MB in the best below. The total gc real-time may be only 0.25-0.5sec but I'd prefer it were closer to 0sec.

Anyway, there's lots to consider. Maybe I'll find some spare time for it.

Your original with operator form: thread_mp_ac1.mw

Here's a larger example (starting from Carl's example), with various flavors of operator versus expression form. Run in 64bit Linux Maple 2019.0 on a quad-core i5.

Using Threads:-Add along with operator form integrands has the best performance of these.

Download cuhreperf.mw

(It's more polite to include a link to your uploaded worksheet, so that nobody else has to type it all out.)

There are a variety of possible ways.

There's less need for extra care and effort if you know that j+1 won't appear anywhere but as an index of T.

Download isol_index.mw

Here is something you might be able to work with.

The basic idea is this. If both sides of the equation are products of terms then do as follows:
 - freeze the multiplicands of both sides
 - divide both sides by the intersection of those multiplicands
 - thaw and simplify

It's quite possible that the freezing/thawing might not be necessary. I put them in to strive for generality. I would not be surprised if there were examples where it helped and other examples where it hindered.

I used simplify(expand(...),size) up front to try and get both sides to be simplified products. But for other examples that might be helped by other means, eg. factor.

By the way, why do you start out with (black) active sum calls instead of (gray) inert Sum calls. Those sum calls don't seem to compute closed forms (ie, they return as unevaluated sum calls). But every time you manipulate or simplify the expressions you have to wait while it tries in vain to compute closed forms for the newer sum calls.

Download common_factors_ac.mw

Download JSON_example.mw

The red spam square appears visible to you because you have elevated moderator status on this site. Most members do not.

The red box only shows for postings by new members which have not yet received vote-ups (and possible Answers, I'm not sure).

If -- as moderator -- you were to remove a posting using thd red spam box then that member's account would also be deactivated.

I delete (as spam) postings from one or two advertisers (cleaning products, rivet wholesellers, etc.) each day. This forum used to be inundated with such. It was a big problem.

There is also a mechanism for moderators to delete unanswered single items ( as "Inappropriate", "Duplicate", etc) without affecting the poster's membership status.

You added material since first asking. I wrote this to address the original bit, where you seem to be asking to reverse the "product rule". First I yank off the extra 1/r^2 factor. Then I integrate wrt r, then do "by parts", and then differentiate wrt r. And then I multiply by the extra factor.

I don't know how much of that you want to automate.

I have not yet looked at the addendum.

Download rev_prodrule.mw

The following does a "hot" edit of VectorCalculus:-D, replacing two uses of apply with direct function application.

It seems to behave so far with Maple 2016.2 through 2019.0.  Let me know if not.

Download VCDhotedit.mw

The regression bug in apply has been reported, along with the unnecessary use of apply in VectorCalculus:-D.

This is just for general interest. I expect the OP may be busy implementing his own Emacs Lisp-based CAS (since Maple, Mathematica, Maxima, Sympy, and Axiom have all failed him) so as to finish implementing his significant improvement over FFT.

It seems that plot is having difficulty recognizing or handling some jump discontinuities (eg, at x=0.0) when that is used as the left end-point of the plotted domain.

Here I'm using Maple 12.02 to try and match your setup.

For three of the plots, if I supply a slightly wider domain (range for x) then the discont=true option seems to kick in ok and the jump is not displayed.

For plt02 I had to use an even wider range, and that one may be suffering a slightly different issue.

ps. I changed the B value for plt11 from 21 to 1, to agree with the other in that group. Perhaps a typo.

It might be possible that in modern Maple the issues could be handled by using discont=[fdiscont=[...]] with some judicious choice of options. I didn't fiddle with that because Maple 12 doesn't offer it.

I see that you've ignored my previous suggestion to compute all these plots much faster using fsolve to solve all the roots at once (per x value). Oh well.

file_discont_ac.mw

Is this adequate for your purposes?

with(inttrans):
sinc := x->piecewise(x = 0, 1, sin(Pi*x)/x/Pi):
S := x->sinc(x):
SE := unapply(simplify(sinc(x)*exp(-x^2)),x);
abs(fourier(convert(SE(x),Heaviside),x,s));
plot(%,s=0..5);

The original definition of SE := x->sinc(x)*exp(-x^2) gets the same plot, if used above instead. The main difference was the conversion of the piecewise to Heaviside before applying fourier. Hopefully I have not misunderstood.

I don't really understand the point of constructing an operator for SE just to plot SE(x), when an expression would do. Maybe you need/prefer an operator later on...

[edit] I see that Carl posted his working revision only moments after I posted this; doubtless we were composing at the same time. The only difference being that Carl put the Heaviside into the defn of SE while I left SE with a piecewise and only converted for the purpose of calling fourier.[/edit]

It looks like gfun:-listtorec can handle this.

You can also use rsolve(...,makeproc) to get a procedure.

Or you can construct a procedure from the recursive formula (with option remember for better efficiency). I could cut and paste the recursive formula obtained from listtorec, but for fun I build it programmatically below.

Download listtorec.mw

I converted your Post to a Question. Please submit your future questions a Questions rather than Posts.

Download Jac_proc.mw

It's not entirely clear to me from your question whether you want a Vector of procedures or a Vector-valued procedure (ie. a single procedure which returns a Vector of the derivatives evaluated at subsequent input points). Your earlier Question about a bug under assume and with VectorCalculus loaded looked as if you wanted a Vector of procedures.

But often a Vector-valued procedure is convenient to utilize subsequently. Hence my use of codegen[JACOBIAN] below.

For example (and accepting a procedure with an arbitrary number of arguments):

Download Jac_proc_alt.mw