@Kitonum Please define the "obvious interpretation" that you're using with some degree of mathematical rigor. I'm not trying to give you a hard time; I truly don't see it. Note that the OP said that a, b, and c could be numbers or variables.

Your Answer requires the user to manually pick off a, b, and c for subtraction. If a and x are both variables, how do you distinguish a from x? why not pick off x? And how could your Answer be used if the original polynomials were expanded rather than in `*` form? And what if the set had an element that was simply a? should it be removed?

Also, I'm not trying to criticize the OP for using erroneous terminology. I have no problem with idiosyncratic terminology as long as it can be unambiguously defined.

@Carl Love One would hope that a Threads version would use a smaller real time than a Grid version. Try this:

Coeffs:= (p,v)-> local M, C:= coeffs(p,v,M); table([M]=~[C]):
Indices:= rcurry(indices, nolist):
searchMonomialsEqns:= (
    conds::set(`=`), Eqns::set(`=`), Vars::list(name), poolofeqns::set(set(set))
)->
    if ({Indices}@rcurry(Coeffs, Vars)@expand@(lhs-rhs))~(subs(conds,Eqns)) in poolofeqns
    then conds
    else
    fi
:
ans1:= CodeTools:-Usage(Threads:-Map(
    rcurry(searchMonomialsEqns, {eqns[1..2][]}, vars[2..3], {{op}~(validYZeqnMon)[]}),
    conds5
)):
nops(ans1);

I've tried to capture the entirety of your code in my few lines, but I haven't tested it. If this gives correct results in a shorter real time, I suspect that that's largely due to the one-time set(set(set)) conversion of validYZeqnMon that happens at the end of the rcurry. 

The above should give the same results as this slightly simpler non-threaded code, which uses select instead of map:

InMonomialsEqns:= (
    conds::set(`=`), Eqns::set(`=`), Vars::list(name), poolofeqns::set(set(set))
)->
    ({Indices}@rcurry(Coeffs, Vars)@expand@(lhs-rhs))~(subs(conds,Eqns)) in poolofeqns
:
ans1a:= CodeTools:-Usage(select(
    InMonomialsEqns, conds5, {eqns[1..2][]}, vars[2..3], {{op}~(validYZeqnMon)[]}
)):
evalb(ans1=ans1a);     

@emendes Two small corrections:

1. [M=~C] should be [M]=~[C]. This is needed in case the polynomial has only one term.

2. indices(...) needs to be indices(..., nolist).

I've already made these changes in the code above.

Your example doesn't make sense. Your set has no setwise common factors. If perchance you're interested in pairwise common factors, the only one is x.

[This Reply was based on the first version of this Question, which referred to removing common factors rather than uncommon factors.]

@Preben Alsholm By the way, I think that there's no practical difference between :-Unit and Units:-Unit; the former is directly converted to the latter.

@J F Ogilvie Googling "define: kid" and scanning the first full page of hits, I find not a single dictionary that marks its definition "human child" as crude (or equivalents such as "offensive", etc.), American, or slang. All classify it as "informal". All except one list this as its first definition. The oldest known usage of this definition is from the 1590s, and it hasn't been considered slang since the 1840s.

Unless theta, q, b, and w have some especially simple form, I'm very doubtful that it's mathematically possible to maximize with symbolic sP and sL.

@michele There is a bad habit among newbies to load unnecessary packages in every worksheet, especially plots and LinearAlgebra.

@emendes Commands, such as coeffs, that return values by modifying their arguments are an unfortunate relic of ancient Maple. It's unfortunate for two reasons:

1. It's considered a bad programming practice in any language.
2. Specifically in Maple, it's impossible for a superficial syntax checker to know whether 'M' means a name through which a value will be returned, and thus should probably be local, or a keyword argument, and thus must be global. So, this is why you unfortunately got no warning about this.

To avoid this and other awkwardness with coeffs, I almost always use it with this wrapper:

Coeffs:= (p, v)-> local M, C:= coeffs(p, v, M); table([M]=~[C]): 

Then after T:= Coeffs(p, v), if only the mononials are wanted, they can be extracted as indices(T, nolist).

@max125 It's instantaneous for me also:

CodeTools:-Usage(plot(sin(t/100), t= 0..1000));
memory used=415.18KiB, alloc change=0 bytes, cpu time=0ns, real time=10.00ms, gc time=0ns

If it's not instantaneous for you, try it in a fresh worksheet.
 

@max125 Yes, by using modp, as in this minor update to John Fredsted's procedure:

expMod := proc(pol::polynom(integer,x),p::prime)
   modp(map(y -> lcoeff(y)*x^(ldegree(y) mod p),pol), p):
end proc:

The p in modp stands for positive.

Your pi(tau) is an unknown function of tau. How can it be possible to solve for tau an equation that contains an unknown function of tau? The only thing that remove_RootOf does in this case is return your original equation. RootOf is just Maple's way of expressing inverse functions. It always uses _Z as its bound variable.

@nm You made a very valuable comment about StackExchange, and I was just about to respond to it, yet now you've deleted it! Please stop doing that!

Unless there's just by chance some physicist reading this who has the specialized knowledge required, the only way that you're going to get any help here is by posting your failed attempts. If the failure is due to a lack of understanding of Maple, it's very likely that we can help. If it's due to something else, it's much less likely.

@DJJerome1976 It is very difficult to program a command to make use of assumptions. The only ones that solve can handle are directional inequalities. The help page that acer linked implies that in the case of directional inequalities, the useassumptions option is equivalent to the method that I showed.