@adel-00 This is still reasonably quick.

Download evalf_int_3d.mw

@vv It can survive garbage collection while there is still some reference to it.

In your example it is still referenced by % (and %% and %%%).

@pauldaas I am guessing that you are showing a reduced example of what you eventually hope to accomplish. But it's difficult to make it the easiest and most robust without knowing in what more general ways you intend on using the code.

But here are two versions that might give you some hints. I've removed the `global` of the procedures because those seem unnecessary (the code assigns the returned results to R, and C seemed to serve no further purpose). I've removed calls to linalg commands. The procedures aF00111 and aM0011 are merged into a single procedure where the key aspect is that the 4th argument passed to it may be, say, F or M. And in one version I've removed L altogether, since there seems no real need to assign to the global names RA,MA,tA,yA when calling aFshear since the entries of R can be utilized directly.

pauldaas_01.mw

pauldaas_02.mw

Hopefully these still operate in a way that blends with your more general (and as yet unstated) purposes.

@Christian Wolinski Those work, too, for the polynomial p I created.

@MDD It only takes a fraction of a second to check hundreds of thousands of entries (in the worst situation that all the polynomials depend on x or y). It may not make much difference to you which you use.

restart;
randomize():

N := 10^5:
S := {seq(randpoly([x,y],degree=3),i=1..N),
      seq(x+randpoly([a,b,c,x,y],degree=3),i=1..N),
      seq(x+randpoly([a,b,c],degree=3),i=1..N)}:

func := S -> not andmap(has,S,{x,y}):

CodeTools:-Usage(func(S));
memory used=13.73MiB, alloc change=0 bytes, cpu time=96.00ms, real time=96.00ms, gc time=0ns
                             false

func4 := S -> ormap(s -> degree(s,{x,y})=0,S):

CodeTools:-Usage(func4(S));
memory used=36.62MiB, alloc change=0 bytes, cpu time=289.00ms, real time=289.00ms, gc time=0ns
                             false

nops(select(s -> degree(s,{x,y})=0,S));
                               0

nops(S);
                             300000

@mmcdara Of course it is necessary to utilize either the set/list of variables or the set/list of parameters. Even though I've edited my Answer (mostly for efficiency), every method I've written has utilized either the variables {x,y} or the parameters {a,b,c}. So I don't follow your point.

Is there some reason why you haven't posted a worksheet which (for you at least) reproduces the problem?

@EB1000 I am not aware of any practical way (or GUI option) to force the Library-generated context items to appear in the right-click popup in Maple 2019.

I also don't see any option to control the destination in the GUI's resource file.

If you could demonstrate that some other installation of Maple 2019 really did offer all the Library-generated items in the right-click popup menu then it'd be quite interesting in how it was configured.

I'm not even sure how I could force/fake it, except by writing a complicated Maplet which utilized the results from the ContextMenu command (and launched that Maplet from an edited version of that command), and which also knew about the ancilliary popup sub-Maplets.

You wrote it as "ConxtextMenu" instead of "ContextMenu".

Or are you saying that right-click on output gives you no popup at all?

@waseem 

You should figure out whether your formulas actually represent what you want.

Help1_ac_k.mw

@waseem I don't understand why you are undoing key aspects of my edits. You're latest attachment had more changes than just the introduction of additional terms.

I deliberately made several changes to your earlier worksheet, including:
1) Adjusting the definition of A so that it matched the formula from your earlier post's question about translation from Mathematica. This produces plots with zero imaginary component, suggesting that it's moving towards the right approach. I don't understand why you have reverted this.
2) Removed applications of evalf to Int calls which had extra options (since doing so removes them).
3) Increased Digits to 15.

In the following worksheet purely real results are obtained using either your latest S1 or the adjusted S1 formula to match your earlier post's definition in Mathematica. So I cannot say for sure which one is correct. Both produce purely real results for plotting, but different results. Likely only you can figure out which is correct.

I cannot know whether your formulas for the additional terms in c2 and e2 are correct. You might have made the same kind of "mistake" as earlier, with the grouping of terms in the denominator. Likely only you can figure out what is correct there.

You should think hard and carefully about those formulas. Just because you obtain purely real results from the integrations does not by itself mean that you have the formulas correct.

I have tried to make the inclusion of extra options (for the numeric integration) come immediately before the plotting, so that even if you once again splatter evalf calls in the formula definitions the plots might still compute. But only you can check that your formulas are correct.

It's possible that you could screw up my edits again, despite my latest efforts to guard against that. If you do I won't be looking at it any more.

I ran this in Maple 16, since I won't have access to Maple 13 until later in the say. But I suspect it will produce plots in your Maple 13 (as I tried the same kind of thing yesterday).

note: You legend values don't match the actual values which you're using for gamma2. I'll let you correct that.

Download Help1_acc.mw

@fatemeh1090 Does this work better in your LaTeX environment?

Naturally, you may wish to break the line (using \\ in the LaTex, or pasting it in by parts, or however you utilize $, $$ \begin{} or what have you).

end_ac2.mw

printf(StringTools:-SubstituteAll(
         StringTools:-SubstituteAll(latex(eval(new,1),output=string),
                     "\\mbox ",""),"\\tt ",""));

\sum _{m=1}^{M} \left( \sum _{k=1}^{N}C_{{{1}}_{{{i,m}}}}\,C_{{{1}}_{{{j,k}}}}\,v_{{{0}}_{{{k,m}}}} \right) -A_{0}\,H_{1}\,\sum _{m=1}^{M} \left( \sum _{k=1}^{N}C_{{{1}}_{{{i,m}}}}\,C_{{{1}}_{{{j,k}}}}\,v_{{{0}}_{{{k,m}}}} \right) -A_{1}\,F\sum _{k=1}^{N}C_{{{2}}_{{{i,k}}}}\,\psi_{\theta_{{{k,j}}}}+{\frac {A_{1}\,K_{4}\,\sum _{k=1}^{N}C_{{{1}}_{{{j,k}}}}\,\psi_{\theta_{{{k,i}}}}}{r_{i}}}+1/2\,{\frac {A_{0}\,K_{4}\,\sum _{k=1}^{N}C_{{{1}}_{{{j,k}}}}\,v_{{{0}}_{{{k,i}}}}}{r_{i}}}

There is no attachment.

@BjaMaple This produces names which prettyprint with subscripts as 2D Output in the GUI.

seq(cat('x__', i), i=1..4);

The code I gave earlier to use x[i] will also prettyprint with subscripts. But the generated indexed names are distinct from those using obtained using the double underscore.

There is also a minor visual distinction: the indexed names display with the subscripts in upright Roman numerals, while the double-underscore form displays with the subscripts in italic just like the base portion of the name. If you really want upright Roman for both, or upright Roman for the subscripts but don't want indexed names like x[1],..,x[4] then let me know. It may be overkill for your needs.