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

You haven't shown the full example that demands loading all of VectorCalculus, or using assume instead of say assuming. So it's not possible to properly address subsequent -- but as yet unstated -- issues you may have.

However,

Download VCD.mw

eqs := {a + b + c = 1,
        a^2 + b^2 + c^2 = 2,
        a^3 + b^3 + c^3 = 3}:

a^4 + b^4 + c^4 = eval(R,solve(eqs union {a^4 + b^4 + c^4=R}));

                        4    4    4   25
                       a  + b  + c  = --
                                      6 
a^5 + b^5 + c^5 = eval(R,solve(eqs union {a^5 + b^5 + c^5=R}));

                         5    5    5    
                        a  + b  + c  = 6

I recall having the same questions, when ColorTools first appeared.

At that time I was able to find, in the internal code, a transformation Matrix corresponding to D50 (which confirmed a few empirical tests). In a subsequent release I noticed that had changed to correspond to D65. But there seems to be little or no documentation about that.

And I believe that by "RGB" the ColorTools package means sRGB, not a wider gamut like Adobe RGB. (Some monitors allow one to toggle amongst such. But I have never tested what effect that might have on what the Maple GUI shows. A missing bit of knowledge might be which the Java GUI's renderer is using.)

Another interesting detail might be just how ColorTools makes certains colors (when converted to RGB from, say, Lab or Luv) "displayable". It's not always clear how it may regress back to the displayable gamut, ie. does it regress linearly back to the white point, or what?

Eventually I wrote my own converters (also via XYZ colorspace) because I wanted them to Compile and be fast on datatype=float[8] rtables representing many colors (eg, images). That gives me full control about the mathematical conversion, though details of the GUI's renderer may still be a missing link in the chain, if I want to visualize.

What form do you want for the results?

Download trighsimp.mw

Do you want something like this?

[edit] Originally I used the range 0*Unit(mm)..100*Unit(mm) along with the accomodating x*Unit(mm) in the calls to tau and Q when plotted. But that only works (by accident) in Maple 2017. So below I've changed the range to 0..100 instead, which makes more sense alongside the argument x*Unit(mm) and which seems to work in both Maple 2017 and Maple 2019.[/edit]

Plot_function_with_units_ac3.mw

[edit] How you approach this may well depend on what you start with. If you have the liberty of entering the initial expression passed to exp (or sin and cos) then it is easier since you can use a replacement symbol for Pi. My suggestions below are more for the case that you've already obtained the -1/2+1/2*I*3^(1/2) form. [/edit]

Here are three related ways.

The first two include examples of printing the inert % form of sin and cos calls without getting the gray elements in the output.

The third way simply delays evaluation (and in consequence is fragile because any subsequent full evaluation undoes the effect).

Download inert_rcistheta.mw

You may also use InertForm:-Display to show the %Pi from Carl's Answer without the gray symbol. Eg,

bar:=cos(2*%Pi/3)+I*sin(2*%Pi/3);
InertForm:-Display(bar, inert=false);
value(bar);

But in that case you cannot so easily extend the `print` facility to make that aspect automatic.

It is possible to adjust the underlying code so that it also colors (extended typesetting mode) typeset math.

The following seems to work ok for me in Maple 2016.2 through to Maple 2019.0.

Tabulate_mathcolor_hotedit.mw

I don't think that you are doing anything wrong. It's not easy to handle the (possible) splitting fields always best, in general. But your example shows that there's likely something to improve. (I'm submitting a bug report.)

Download evals_ac.mw

I have previously submitted bug reports for examples such as this where simplify(...,size) does not compress as much as can a judicious collect with simplification of the ensuing coefficients.

In this example that situation occurs for the subexpression within the radical.

I have an oracle that speculatively tries collecting w.r.t. the relevant names in the subexpression (sum), and indicates which compresses well or best. Hence the following suggestions, relating to collect w.r.t. g. These vary a little because more generally you may or may not want other kinds of simplification effects:

Download simplification_under_sqrt_ac.mw