@mmcdara Your code covers only the first part of the exercise, which isn't so bad. And of course your code is an interesting solution that goes far above and beyond the scope of the exercise. It's the other two parts of the exercise that really put it over the top for me: the part about what to do if a random value is 0 and the part about selecting random values from the matrix.

The ugliness is compounded by the fact that direct user input is inherently ugly in Maple. This is the fault of Maple, not the instructor, but the instructor should know better than to assign an exercise requiring it.

@emendes The rcurry is just a syntactic convenience for makIing extra arguments the default. It has nothing to do with efficiency. For example, I almost always want to use the extra argument nolist with the indices command. So, after doing 

Indices:= rcurry(indices, nolist),

Indices(T) is equivalent to indices(T, nolist).

If the new code is significantly faster, it's due to using sets instead of lists. Search time through sets should be shorter due to them being stored sorted.

@Jaqr Yes, your idea cleverly gets around the issue by ignoring the V after the first primpart command is done. I hope that this works for all csses.

@Jaqr Yes, @ is the function composition operator in Maple, or, as you say, sequential application.

@Jaqr For reasons that I don't know, the command primpart intentionally doesn't divide out the sign. But there is a sign command for that. So, here's a correction:

RemoveUncommomFactors:= (S::{set,list}(algebraic), V::set(name))->
    map((p-> sign(p,V)*p)@primpart, S, V)
:

@Jaqr Yes, it's precise enough. I think that the rule can be stated more briefly: Discard any factor that doesn't contain a category-1 variable. Do you agree?

Please test the above. I am eager to know whether it produces correct results, and, if so, whether it beats a Grid version in real time.

You've edited the Question in such a way that the subsequent discussion makes no sense. In the future, please don't do that. Instead, use a Reply. Editing the Question is fine as long as you maintain the continuity of the subsequent Answers and Replies.

Okay, you now say that you want to remove uncommon factors. Can you be more precise about what makes a factor uncommon? Is it that it appears as a factor in exactly one of the elements of the set/list? Can you give a few more-elaborate examples of input sets (with associated variable sets, if needed) and your desired output from each? In your original example, x+y appears as a factor only once; so why is it not also uncommon?

Salma, this comment is not directed at you, but rather at the instructor who assigned this exercise to you.

This exercise has no practical value! This is the worst Maple exercise that I've ever seen in the 20 or so years that I've been doing this. Occasionally one may write a Maple procedure (or undertake any mathematical endeavor) for its aesthetic rather than its practical value, but, alas, this is also the ugliest Maple exercise that I've ever seen.

@max125 If you edit the Question, that also keeps it active. You don't need to actually change anything; just load it into the editor and resubmit it. This only works for top-level Questions and Posts; it doesn't apply to Answers, Replies, or Comments. 

Regarding deleting; Absolutely do not ever delete or significantly modify anything that has been responded to. To me, that's the rudest possible thing that anyone ever does here.

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