@radaar Computing a numeric integral using a Riemann sum is not a good way to try and get better performance.

So really this is just another one of your several posts about the performance of certain numeric integrals, but with less details and context given up front?

If your procedure is evalhf'able and you want to get better performance then why not give us the full example?

Perhaps it will also be Compilable. Or perhaps how you utilize the procedure might be parallelized. Or perhaps other performance optimizations are possible.

Providing so little context to us is not very helpful.

You have a history of posting questions on this site with no supporting details, context, or example.

Is this your full question?

@vanzzy I understand now. Sorry if I sounded harsh.

@Samir Khan There should be no need for specifying what could be done with an imported .mp3 audio file, as it could reasonably be whatever is done with an imported PCM or ADPCM WAVE .wav file (which up to Maple 2019.0 is the only format documented as being supported by the AudioTools:-Read command).

Here is another (tentative) kind of workaround,

restart;

unprotect(apply);
apply:=proc(p) p(_rest); end proc:
protect(apply);

with(VectorCalculus):

assume(x::real);
assume(y::real);

D[1]((x,y)->x^2-y^2);
       (x, y) -> 2*x

D[2]((x,y)->x^2-y^2);
       (x, y) -> -2*y

D(x->sin(x^2));
    (x) -> 2*x*cos(x^2)

What happened between Maple 2015.2 and Maple 2016.0 was that apply was changed. Here it is in Maple 2015.2. I'll note that it had issues dealing with procs with special-evaluation rules.

kernelopts(version);
   Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895

showstat(apply);

  apply := proc(p)
     1   p(args[2 .. nargs])
  end proc

apply(Typesetting:-Typeset, sin(x)):
#lprint(%);
# wrong result omitted by me

And here it is in Maple 2016.0. It handles that particular spec-eval-rules example, but it can go awry on some examples with assumed names.

kernelopts(version);
   Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701

showstat(apply);

  apply := proc(p)
  local P;
     1   eval(subs(P = p,P(args[2 .. nargs])))
  end proc

apply(Typesetting:-Typeset, sin(x)):
lprint(%);
  Typesetting:-mrow(Typesetting:-mi("sin", fontstyle = "normal"),
                    Typesetting:-mo("⁡"),
                    Typesetting:-mfenced(Typesetting:-mi("x")))

That implementation of apply in Maple 2016 goes wrong as used in VectorCalculus:-D under certain assumptions. (That use relates to my earlier Comment in this thread where I examined the addressof certain variables under those assumptions.)

The implementation for apply shown in the workaround above also handles that particular spec-eval-rules example, but doesn't break as used by VectorCalculus:-D under the assumptions in the original example. Ie, apply:=proc(p) p(_rest); end proc .

I should mention that I do not know how this alternative definition for apply would fare under a full regression test suite run. So I'm not going to advise anyone stick it in an initialization file.

I could also mention that I doubt that any purely Library-side implementation of apply can mimic special-evaluation-rules perfectly. Using apply already involves one full evaluation of the extra arguments, since it does not have spec-eval-rules for any extra parameters. The eval(subs(...)) approach in Maple 2016 adds yet another evaluation, so it looks more suspect. Consider the example apply(sin, ''2.1''), which returns sin('2.1') in Maple 2015.2 and also with my tentative apply implementation, but which returns a float like 0.863... in Maple 2016.2.

note. From the ?paramprocessing help page, "Like evaln, uneval can only be used for required positional parameters. It also cannot be used in conjunction with any other modifiers, or in a parameter declaration after one with the seq modifier." So putting spec-eval-rules on all extra parameters in a Library-side implementation of apply seems problematic.

@Carl Love My own Answer also (already) had an example that handled an operator (rather than an expression) using codegen[JACOBIAN].

So far the OP has ignored that germane example in my Answer. Instead he's chosen to focus on my Reply to Tom's Answer (both of which dealt with expressions) and disingenuously mischaracterize its intent.

@DoingMath2018 No, your previous posting shows that VectorCalculus:-D is broken (on procedures defined after certain kinds of assumptions made and after all of VectorCalculus is loaded). It's not useful to mischaracterize the details.

Did you only load all of VectorCalculus so you could try out its Jacobian export, or were there other pressing needs? And you never addressed my query of why you utilize assume rather than assuming. Why ignore all workarounds?

[edit]Anyway, the only reason I used D at all is because you had failed to mention up front that you wanted an array/vector-valued procedure rather than a Vector of procedures. I was misled by *your* own use of D in your other posting. It's not the right tool for the vector-valued procedure job. The codegen commands are. And as soon as you clarified I supplied a codegen[JACOBIAN] example.[/edit]

@tomleslie Tom, regarding your first example the behavior seems to be related to this difference between Maple 2015.2 and 2016.0.

restart; kernelopts(version);

     Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895

assume(x,'real'); assume(y,'real'); f:=(x, y)->x^2-y^2:

map(addressof,[op(1,:-eval(f))]);

        [18446883966034675422, 18446883966034683358]

map(addressof,[op(indets(f(op(1,:-eval(f)))))]);

        [18446883966034675422, 18446883966034683358]

map(addressof,[op(indets(apply(f,op(1,:-eval(f)))))]); # agree

        [18446883966034675422, 18446883966034683358]

restart; kernelopts(version);
                         
     Maple 2016.0, X86 64 LINUX, Feb 16 2016, Build ID 1113130

assume(x,'real'); assume(y,'real'); f:=(x, y)->x^2-y^2:

map(addressof,[op(1,:-eval(f))]);

        [18446884548440282622, 18446884548440291006]

map(addressof,[op(indets(f(op(1,:-eval(f)))))]);

        [18446884548440282622, 18446884548440291006]

map(addressof,[op(indets(apply(f,op(1,:-eval(f)))))]);  # differ

        [18446884548440289598, 18446884548440291998]

And VectorCalculus:-D is using apply, at a key juncture rather than making a function call directly, and so the names don't match when taking the derivative (hence the 0 result).

showstat(VectorCalculus:-D,20);

   VectorCalculus:-D := proc(f)
   local Opr, Index, d, i, n, sol, g, idx, F, x, _F, bb;
          ...
     20       g := apply(d,sol);
          ...
   end proc

I do not know whether this version specific change in behavior (of apply, under assumptions) was intentional, or whether there is some reason why VectorCalculus:-D utilizes apply.

@dharr I agree, and I apologize if I came off the wrong way.  Vote up, btw.

In versions Maple 2016 and earlier the Java GUI had a user-preference which could be set to display legends automatically for 2D plots. But that seems to have been removed/disabled in Maple 2017.

It was a checkbox, avaiable via Tools->Options-Display from the main menubar.

It labelled the multilple curves like, "Curve 1", "Curve 2", etc, alongside short line segments of the appropriate color.

@dharr Your call to rsolve solved the mixed recurrence to obtain a closed form formula for the general term. And perhaps that is what the OP actually wanted at end.

But the OP asked for the "general recurrence" (involving s(n), regardless of parity) which is not the closed form formula for the general term.

@tomleslie If you execute SE(x) in your code then the result is just sin(Pi*x)*exp(-x^2)/(x*Pi) , and that is what is being passed to inttrans[fourier].

So, as far as taking the fourier transform goes, you've got the same thing as Carl's initial response. By which I mean that the exprerssion obtained by the symbolic call SE(x) no longer contains any piecewise, Dirac, unevaluated `if`, or other mechanism to handle the singularity. But it seems that the OP did want that generality.

@DoingMath2018 If your input procedure doesn't have conditionals and branching (ie. are simple operators that utilize a formula) then handling an arbitrary number of dependent variables and instead using an expression doesn't seem to present great difficulty.

For example (noticing that the dummy variable of integration, r, is correctly skipped and is not one of the independent variables):

Download VCJ_arb.mw

Above I have constructed a single Vector-valued procedure rather than a Vector of procedures. I'm not sure which you want.

If you really do prefer to use an input operator rather than an input expression then you could look over my Answer above.

I think it would be easier to learn how to leverage Maple's functionality than it would be to implement your own basic CAS.

It is still unclear to me how you plan to subsequently utilize this Jacobian-thing that you're after. Providing more details of the input example class and also how the result will be subsequently utilized should surely be a core part of the question.

Have a look at the Help pages for the Student:-Calculus1 package.