@Christopher2222 No, that is not a good point. It muddles concepts and doesn't make sense in general.

And in fact you have your example wrong/backwards. But even if you corrected it then you'd be in a position that I anticipated when I wrote above that instead you should utilize an equation. That's because in general your proposal is unworkable, generally ambiguous, and does not make sense.

It doesn't make sense, as you've described it.

If you want to utilize an equation... then do so. You can even assign the equation (which you may utilize) to a name.

But what you've described does not make sense that I can see. You are muddling concepts.

@gaurav_rs Using Maple 2017.2,

for dig from 10 to 20 do
  Digits:=dig;
  forget(evalf); forget(int);
  res := int(fnormal(F1), [theta= Pi/4..7*Pi/4, r= 0..1]);
  printf("Digits=%a  %f\n",dig,res);
end do:

  Digits=10  -1152122349000.000000
  Digits=11  -1116001007100.000000
  Digits=12  -1116001007190.000000
  Digits=13  -1116001007191.000000
  Digits=14  -1116001007191.800000
  Digits=15  -1116001007191.800000
  Digits=16  -1116001007191.796000
  Digits=17  -1116001007191.796500
  Digits=18  -1116001007191.796470
  Digits=19  -1116001007191.796470
  Digits=20  -1116001007191.796470

@Carl Love Yes, of course, thanks.

@Kitonum In my first Reply/Comment on the Question I mentioned, "It might also matter whether you need to be able to export them (say to an animated GIF file) which plays them together."

I wrote that because the method that you've shown right-click exports only one of the animations to a single animated GIF file.

That related to why I wrote an Answer as I did.

@Kitonum It'll be interesting to find out what the OP really wanted. I interpreted "...sync two or more different animations" to mean two or more separately displayed animations and have them play in a synchronized manner.

In a followup Comment he added, "...just different x and y scale which is irrelevant since they will be on different plots."

I figured the OP meant in unison and separately when he wrote sync and different. Perhaps you are right, though, in interpreting that he meant together.

@Stretto And did you read the post to which I linked? It seems to cover your example.

In case it may relate to your goal, you could look at this stackoverflow post. Note that it deals with a synchronized display of an array plot, rather than two animations which have already been constructed.

One aspect that seems relevant is whether the two animations have the same number of frames (one a multiple of the other). If that's not the case then it could get tricky -- possibly requiring an adjustment if you want them to finish/loop concurrently.

It might also matter whether you need to be able to export them (say to an animated GIF file) which plays them together.

Perhaps you could supply your actual example, with full detail to reproduce.

What does the sum (of numeric integrations) over the xx[i] represent?

Is it possible that you are trying to integrate (the inner numeric integrals) over "xx" in a given range? I mean, does the final sum total, divided by the number of terms in the sum, (possibly in the limit) represent something meaningful in your goal?

If so then it might be a better idea to simply numerically integrate over one more dimension.

Just an thought. I have little idea of what you're really trying to accomplish because you haven't explained it.

@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.