@MDD Your procedure seems to work so far. My knowledge of Groebner bases is minimal. I think it's great that you were able to write the Maple procedure on your own. Yes, it is probably a better way than eliminate.

@MDD 

I didn't "deduce" that you were rude and evasive; that's just my opinion. I don't want thanks later; I want to know what you're working on, now. You still haven't provided a title. State in clear mathematical language the "new result" that you are trying to prove.

@MDD 

Considering the huge amount of extremely detailed help that you've received here at MaplePrimes in the last few weeks, I consider the vagueness and brevity of your Reply to Axel to be rude and evasive.

What is the title of your "main project"? Are you developing an algorithm? Trying to prove a theorem? 

@rit 

It is no surprise at all that you are banned on StackExchange. Please tell that to the psychiatrist; I'm absolutely sure that he or she will find it relevant. Unfortunately, MaplePrimes is not as well organized as StackExchange.

I've been reading your Questions on MaplePrimes for about two years, and I've tried to answer a few of them. I've given up on that because you are mentally ill. Please seek psychiatric help. I don't mean to offend you; I am saying this in all seriousness and out of a desire to help you. I know that you live in Hong Kong, so I would guess that you have access to some sort of public health facility.

You constantly ask questions about higher-level math when it is obvious that you don't understand the necessary lower-level math. For example, in this Question you are asking about a high-level concept (free groups), yet it is clear that you don't fully understand the low-level concept of equivalence relations. It seems like a lot of your math knowledge comes from reading, at random, the help pages of computer-algebra packages.

You constantly ask questions about obscure Maple commands in abstract-math packages when it is clear that you don't understand basic Maple. You write page after page of nonsensical Maple code where you repeatedly type out long command names like MatrixMatrixMultiply(A,B) to express simply A.B. I believe that you have a symptom called hypergraphia which you express through writing Maple code. Please tell that to the psychiatrist.

On the rare occasions when someone answers one of your Questions, you never seem to accept or understand the answer.

From this point forward, I am just going to delete any Question of yours that I judge to be either irrelevant or nonsensical. Unfortunately, there is no formal process for deletion like there is on StackExchange. 

I hope that you go somewhere where you can get the help that you need. After that, you may start asking basic, sensical, and relevant Questions which I'll be happy to answer.

[If anyone doubts what I say here, please read through the OP's massive list of 341 Questions before criticizing me.]

@MDD 

There's no file attached to your most-recent Reply.

@MDD 

I was able to make a change so that the procedure handles this latest case, but I don't understand why it works. The change is to reduce the equations with respect to Null (using simplify with side relations) before calling the solver eliminate. I hope that someone else can jump in here and help (Roman? Acer?). Specifically what I don't understand is, given that

1. P1 and P2 are sets of polynomials,
2. C is a set of names that occur linearly in P1, and
3. none of the names in C occur in P2

then how could eliminate(P1 union P2, C) return results fundamentally different from eliminate(simplify(P1, P2), C)? And what is a minimal example where this happens?

Here is the new procedure:

ExtPolyLinearCombo:= proc(
     F::list(polynom),
     f::polynom,
     V::set(name),
     Null::set(polynom):= {},
     NotNull::set(polynom):= {}
)
local
     c, k, C:= {c[k] $ k= 1..nops(F)},
     S:= eliminate(simplify({coeffs(expand(`+`((C*~F)[]) - f), V)}, Null), C)
;
     if
          lhs~(S[1]) <> C or
          not simplify(S[2], Null) subset {0}
          # or not andmap(s-> is(denom(rhs(s)) <> 0), S[1])
          # assuming (NotNull <>~ 0)[], (Null =~ 0)[]
     then
          return false, []
     end if;

     true, eval([C[]], S[1])
end proc:

@MDD

I think that it's a bad idea given that the NotNull conditions are in general polynomials and not individual variables. There may not be any solution where those polynomials are all equal to 1. 

Your post has no attached file---no code, no picture.

@tomleslie 

Yes, your new method works. And I just thought of a another way using unapply, this one less cryptic:

G:= unapply('add'(F(f,x,y,ll), ll= 1..n), [x,y,n]);

@tomleslie 

The problem with all three of your methods is that they cause the limit to be evaluated multiple times. You can give the command debug(limit) before executing G to see how many times limit is called. In addition to just being generally wasteful, it is clear in the Question (and even in its title) that the OP wants the limit evaluated before the call to G (indeed, even before the definition of G).

You may be especially surprised that your third method also suffers from multiple limit evaluations; however, it does because of the special evaluation rules of add (which also apply to seq and mul), which re-evaluate the first argument for every value of the index. So, you may think that you can avoid this by calling limit before the add but still inside G. Something like this:

G:= proc(ff::procedure, x, y, n)
local ll, L:= limit(ff(x,y), y= ll);
     add(L, ll= 1..n)
end proc:

This does call limit only once, but the answer returned is wrong, indeed, ridiculous, as it still contains ll. I urge you to try it yourself and see.

The way around this is to use subs to modify a "shell" procedure into a working procedure, like this:

f:= (x,y)-> sin((x+y)/y):
F:= (f,x,y,L)-> limit(f(x,y), y= L):
G:= proc(x, y, n)
local ll;
     add(_FF, ll= 1..n)
end proc:

G1:= subs(_FF= F(f,x,y,ll), eval(G)):

G1(a,b,10);

Note that this allows reference to the locals and parameters of G outside of G itself. 

There is another "clever" way to achieve this with unapply and no subs:

G:= unapply('`+`'(F(f,x,y,ll) $ ll= 1..n), [x,y,n]);

Note that the + is enclosed in both name quotes and unevaluation quotes.

@w-Teilchen Use solve---it's even more direct than roots, as in -solve(numer(q)), etc.

Forget about patmatch. It's definitely not the way to solve your problem.

If both solve and roots don't work for you, please post an example problem for which that is true.

@wolverine Okay, you've substantially cleaned up the code by using my redefinition of ode. But you haven't answered my question about what you mean by D[1] and D[2]. As it stands, they are being treated as the derivatives with respect to the first and second independent variables, respectively. Is that what you intend?

@MDD Please post this as a new Question (a new thread). This is far, far removed from the original Wronskian-related Question of this thread. It has very little to do with PolyLinearCombo. It's substantially more complicated than your previous questions. And I think that more people will seriously think about it if it's a new Question.

In the new Question, please mention

1. whether f and the members of F are always homogenous in the variables. (I don't immediately see that that makes a difference, but any restriction that you can make on the complexity of the problem can't hurt.)
2. whether the coefficients of f, the coefficients of the members of F, and the members of N are all always polynomials in the parameters (or contant). 
   

@Dmitry Lyakhov Mac Dude's nested loop code should work. If it doesn't, perhaps you have an installation bug. Please post an executed worksheet showing it not working.