## 22125 Reputation

15 years, 222 days

## look like it...

@dharr Yes, it looks like it may just be reformulated as,

K1*Int(cos(theta),theta=0..2*Pi) + K2*Int(sin(theta),theta=0..2*Pi)

where K1 and K2 do not depend on theta.

070919_ThetaIntegral_ac.mw

@9009134

For example,

int3_ac.mw

## like this?...

@adel-00 Is this what you are trying to accomplish?

Apart from other problems including misuse of assumed names, your sprintf calls tried to use Lambda as if its value were a float, but it is unassigned.

 > restart:
 > #assume(theta,real):assume(phi,real):assume(d,real): #assume(tau,real): tau0 := 1:
 > term1:=(exp((1+I*d)*Gamma*tau)*(1-cos(2*Omega1))+cos(2*Omega)*exp((1+I*d)*Gamma*t0)-exp(-(1+I*d)*Gamma*t0))/(2*(1+I*d)): term2:=-1/2*int(exp((1+I*d)*Gamma*x)*cos(Omega1*(1+erf(tau))),x=-1..1): J1:=(term1+term2): J1mod:=(Re(J1))^2+(Im(J1))^2:
 > ###### J2######################### A2:=int(exp((1+I*d)*Gamma*x)*sin(Omega1*(1+erf(tau))),x=-1..1): A3:=sin(2*Omega1)*(exp((1+I*d)*Gamma*tau)-exp((1+I*d)*Gamma*t0))/(1+I*d):
 > J2:=-I*(A2+A3):
 > J2mod:=(Re(J2))^2+(Im(J2))^2:
 > #J3 same as J1differ in sign term1:=(exp((1+I*d)*Gamma*tau)*(1+cos(2*Omega1))-cos(2*Omega)*exp((1+I*d)*Gamma*t0)+exp(-(1+I*d)*Gamma*t0))/(2*(1+I*d)): term2:=0.5*int(exp((1+I*d)*Gamma*x)*cos(Omega1*(1+erf(tau))),x=-1..1):
 > J3:=term1+term2: J3mod:=(Re(J3))^2+(Im(J3))^2: J4:=-J2: J4mod:=(Re(J4))^2+(Im(J4))^2:
 > #calculate the spectrum Spec:=J1mod+J2mod: #Spec:=J1mod*cos(theta/2)^2+J2mod+J3mod*sin(theta/2)^2 #      -0.5*Re(J3*J4*sin(theta)*exp(I*phi))+0.5*Re(J1*J4*sin(theta)*exp(-I*phi)):
 > with(plots):
 > Omega:=1:tau:=Pi:tau0:=1:Omega1:=0.5*Omega*tau0*sqrt(Pi):Gamma:=0.05:t0:=0.75:theta:=0:phi:=0:
 > tit:=sprintf("l=%a,W=%g,G=%g,q=%g,f=%g",l,Omega,Gamma,theta,phi);

 > P1:=plot(Spec,d=-350..350,axes=boxed,numpoints=200,title=tit,color=black,          font=[2,3,18],thickness=2,tickmarks=[3,3],gridlines=false,          labels=["",""],          titlefont=[SYMBOL,14],font=[1,1,18],linestyle=1);

 > Normalize:= proc(P::specfunc(anything, PLOT))   local A,Smax1;   A:= op([1,1], P);   Smax1:= max(A[..,2]);   if A::list then A:= Matrix(A) end if;   A[..,2]:= A[..,2]/Smax1;   subsop([1,1]= A, P); end proc:
 > P1:= Normalize(P1): for kk from 2 to 5 do   tau0:= kk*Pi;   P||kk:= plot(Spec,d=-350..350,axes=boxed,numpoints=200,title=tit,color=black,                font=[2,3,18],thickness=2,tickmarks=[3,3],gridlines=false,                labels=["",""],                titlefont=[SYMBOL,14],font=[1,1,18],linestyle=1);   P||kk:= plottools:-translate(Normalize(P||kk), 0, kk-1) od:
 > display([P||(1..5)],view=[-350..350,0..5]);

 >

## expand...

@Rouben Rostamian  The OP gave a target rhs in which most of the original (diff-unrelated) terms were not expanded. Kitonum called collect (wrt R1) to undo that effect, but that is a slightly ad hoc or manual intervention.

I surmised that the OP wanted the remaining rhs terms left mostly as is, perhaps even more so than in the supplied target.

By using either collect or expand the diff terms can be initially separated. But by using collect for the initial separation of the derivatives there is less expansion to undo, for this example.

And if the leading sign is not crucial then my answer is shorter still.

There are other kinds of example where the effects of expand can be troublesome to undo. Sure an expanded call like sin(a+b) can be undone using combine. But there may be other trig products in the original which one doesn't want combined into a sum of trig calls on sums. Sometimes a frontend'ed call to expand can serve, but that's more effort to invoke.

And there are other related examples -- originally only partly expanded. Calling expand may expand too much, so that recovery of the very same extent of expansion is hard or practically impossible.

So it's my preference to not call expand, generally, if something else serves reasonably.

More specifically for this particular example: the OP wrote that he wanted the derivative terms to be collected, and he even provided a target that illustrated that. Now, the following accomplishes that but seems inferior because,
1) it calls both expand and collect, yet as I showed only collect is needed, and,
2) it expands all the remaining rhs terms, which would requires a rather ad hoc call to undo.

((L,R)->collect(L,diff)=-R)(selectremove(has,expand((rhs-lhs)(eqn)),diff));

## ok...

@adel-00 This is still reasonably quick.

 > restart;
 > kernelopts(version);

 > evalf(Int(exp((5+I*6)*x)*sin(1+erf(x)),x=-1.2..1.2));

 > restart;
 > igrand:=exp((5+I*d)*x)*sin(1+erf(x)):
 > Ref:=evalc(Re(igrand)): Imf:=evalc(Im(igrand)):
 > f:=proc(c,dd) options remember, system;   if not [c,dd]::list(numeric) then return 'procname'(_passed); end if;   evalf(Int(eval(Ref,d=dd),x=-c..c, method=_d01ajc,_rest)         +I*Int(eval(Imf,d=dd),x=-c..c, method=_d01ajc,_rest)); end proc:
 > CodeTools:-Usage( f(1.2, 6) );

memory used=395.27KiB, alloc change=0 bytes, cpu time=8.00ms, real time=14.00ms, gc time=0ns

 > CodeTools:-Usage( plot3d([Re(f(s,t,epsilon=1e-3)),                           Im(f(s,t,epsilon=1e-3))],                          s=0..1, t=-2*Pi..2*Pi, color=[red,blue]) );

memory used=127.04MiB, alloc change=37.00MiB, cpu time=1.03s, real time=974.00ms, gc time=122.67ms

 >

## until it's not referenced...

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

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

## purpose?...

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

## comment...

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

## all quick...

@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

## sure...

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

## one way...

I've removed my Answer since the Question has been changed.

## code to reproduce...

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

## not as far as I know...

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