@Kitonum On the line that assigns to single try using the prefix form for the call to &not, as a function call using brackets.

Error_ac.mw

It works in Maple 2018.2 using

  &not( ... )

and, fwiw,

  NULL &not ...

@mmcdara Unfortunately the approach you've given does not do as well in later versions. You used Maple 2015, it seems.

But with two little tweaks it can still serve. (See my Answer as to why, if you'd like.)

Download int_mmcd_ac.mw

@Carl Love The crash is due to the evalf of these Int instances at higher precision (see my Answer, eg, at Digits=25 or so).

Yes, it's true that it would be better if fsolve didn't try and demand that kind of precision increase. But the bug is in evalf(Int(...)) .

@pauldaas 

It's too bad that you've ignored all my previous suggestions. Your code still uses deprecated linalg and matrix, unnecessary stacking to iteratively build the Matrices, unnecessary globals, and substitution done via unnecessary assignment to the list of key names.

This code is severely flawed. It is unnecessarily fragile and will likely cause future grief.

It's also too bad that you could not properly explain the purpose of the code. Comments about load forces on a beam are irrelevant. What would be useful would be information about why you need to build R row by row, whether you really need C at the end (or just R), whether you know the number of rows in final R, etc.

I would not be surprised if a robust and sensible version of code to accomplish your true goals could be only a few lines long.

It's too bad that you ignored all my suggestions in a previous thread. Your code still uses deprecated linalg and matrix, unnecessary stacking to iteratively build the Matrices, unnecessary globals, and substitution done via unnecessary assignment to the list of key names.

This code is severely flawed. It is unnecessarily fragile and will likely cause future grief.

@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

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

Download adel00.mw

@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));

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