@dharr but there must be some systematic way to find the n-generic limit form.

Maybe here I make some progress: generic_n-form_of_infinity_limit.mw

That is, I introduce X[i] and X[j] as functions of gamma before taking the limit for gamma to infinity of the whole expression. Now W is not anymore W = (stuff1)*gamma+(stuff2), so its limit does not have to be +/- infinity. In fact I think that it should not be infinite, given that for n={2,..,6} the limit behaves well (see my comment above).

However, I still encounter the signum() issue even when I impose positivity on lambda and lambda__r (while leaving them undefined for now). Can it be that I get the signum() because of all the summations on the deltas? Weirdly, the computation introduces summations over _a indexes: where these come from? Did I not understand the syntax of summations in Maples? X[i] and X[j] are exactly the same, where the second term is delta[i] and delta[j], respectively, and the last term is a summation over all the other respective deltas...note that X[i] and X[j] enter W inside a double summation...

Thanks!

@dharr I did not mention an important detail. My X and lambdas were themselves limits to infinity of gamma-generic X and lambda. So I now understand why I got the structure W = (stuff1)*gamma+(stuff2) (with obviosuly infinite limits for gamma to infinity) while the actual behaviour of my series for fixed n is finite.

Given this, I suspect that approach B would be the way to go, but where I replace my X and lambda definitions with their gamma-generic forms. However, these are RootOf() and I expect the limit calculation to take even longer then...
Is this how I should proceed? Or is there any simpler way to deduce the generic-n limit form by just inspectinf the series for n from 2 to 6?

@dharr I included an update to my post. So the argument of the signum() function might be badly specified because of how I defined X[i] and X[j]? I also included how my limit looks like for instances of n. It's finite. This could be helpful in finding the generic-n form of the limit I am looking for. 

I agree approach A is the right way to go, but I am not sure I follow what you have in mind... 

plot(eval(W, [n = 3, w = 1, Delta = 1, vo[i] = 1, rho = 0, sigma__v = 1, sigma__d = 1, sigma__dr = 1, X__r = 3, X[1] = 3, X[2] = 3, X[3] = 3, lambda = 2, lambda__r = 5, delta[1] = 1, delta[2] = 2, delta[3] = 3, delta__r = 1]), gamma = 0 .. 10)
gives me a warning. This is probably not what you meant. 

I attach the result of the almost 1 hour-long computation.

Infinity_limit_and_summations_result.mw

The signum issue persists also with approach B. So it's something I'll need to address regardless of how I approach the limit calculation. Despite the assume(), radicals with rho and n are not combined as I expected...

Moreover, looking at the result, I think I have badly defined X[j]. X[j] is none other than X[i] but with j<>i. Similarly, delta[j] is none other than delta[i] but with j<>i. The restriction j<>i means, for example, that if i=2 then j={1,3,4,5..n}. So I think k-index is redundant...
How do I redefine X[i] and X[j] to reflect this? I am not very familiar with Maple's sum(). 

SERIES FOR n=2..6:
I attach my limits for fixed values of n: n_from_2_to_6_-_Infinity_limit_and_summations.mw. This could be helpful in "visualizing" the form of the generic-n series that I am looking for.

@vv I got it now. Thanks a lot for clarifying. I didn't see it in this way before your comments, but now it makes sense.

@vv yes := instead of =... Sorry for the stupid typo.

Yes, I understand that that diff doesn't work as I would like to... when X[i] is in sum(X[i],i=1..n), how do I compute the derivative for a fixed i?
For example, the derivative of X[1]^2+X[2]^2+X[3]^2+... wrt X[i] is 2X[i] with i={1,2,3}, not 2X[1]+2X[2]+2X[3]...

Moreover, regarding simplify(), it doesn't work as expected, that is, some terms that should simplify actually don't because simplify() doesn't seem to catch the linearity of sum:

for example, simplify(sum(a[i],i=1..n) - sum(something1+something2+a[i],i=1..n)) does not produce -sum(something1+something2,i=1..n)!!

@vv yes I couldn't explain that difference term. I must have done something wrong when calculating "DB_correct" with pen and paper.

What about the evaluation issue in complete_derivative.mw? Both eval() and simplify() do not work as expected when applied to DXI and DXR...

@vv of course! naive me.

DA works now, what about DB? Did I make any mistake when deriving DB_correct with pen and paper? NEW_derivatives_of_summations.mw

Overall, I want to compute these two derivatives (why I can't evaluate them for given w, n, and rho?)

Download complete_derivative.mw

I think @C_R reply helps me with defining the system of n equations. I'll need to check. However, my doubts about summations and derivatives of summations in Maple persist.

@Ronan from your reply I learnt that excluding j=i cases is done by splitting the inner summation into two pieces: j from 1 to i-1 and j from i+1 to n. That's ok, it's like on pen and paper. But please check my example below, where I show you what I am concerned about.

Download derivatives_of_summations.mw

@C_R 

Partial derivative of a summation: why it is not just 2*`X__i`?
I am not sure I understand what you mean. Suppose n=3. Then A=X_1^2+X_2^2+X_3^2. For any i from 1 to 3 the derivative is always 2X_i, that is, for i=1 is 2X_1, for i=2 is 2X_2, for i=3 is 2X_3. Why their sum?

Partial derivative of a double summation: how to define the nested structure of a double summation where j<>i?
I cannot see how B_wrong is calculated, and Sum it's just an inert form so not that useful. In any case, B_wrong is surely not correct since I never really included the j<>i constraint on the index (the summation over j has to skip j=i). How do I do this?

System of n equations: how to define and solve for it?
I wanna solve this generically. That is, if I have n+1 equations where n of them are functions of X_i (and X_j) and the last one of X_r, the output solution is X_i=... and X_r=...  

@dharr thank you for the useful note.
Given the Jacobian, is this correct? compact_derivatives_putting_all_together.mw

@dharr thanks for clarifying. Yes Veil[] works good here before differentiation: compact_derivatives_Veil.mw

EDIT: there must be some smarter usage of alias(), but the script above is a start...

@dharr "Following RootOf is in the derivatives, so alias it.": where is it? isn't it the case that it's in the derivatives of X__2 only because it's in the derivatives of X__1 but which we haven't specified yet? Why would we care about any RootOf() in the derivatives of X__2 before even specifying X__1? Isn't X__1 the only "source" of any RootOf()?

I was hoping to get something nicer looking with

***with(LargeExpressions):
compact := collect(dX2dy1, [X__1(y__1,y__2),Diff(X__1(y__1,y__2),y__1)], [Veil[A],Veil[B]] );

but no output...

***this command is maybe wrong: I don't know how and I never used collect(,veil[]) with two wrappers. I was thinking of A[i] as the coefficients on X__1(y__1,y__2)-terms and B[i] as the coefficients on Diff(X__1(y__1,y__2),y__1)-terms. (and similarly for dX2dy2.)

@janhardo mmm, not too clear to me. Would you mind explain? Do you mean I need to insert diff(Lambda_1,Gamma_1) and diff(Lambda_1,Gamma_2) somewhere in diff(Lambda_2,Gamma_1) and diff(Lambda_2,Gamma_2) for the latter diff() to "capture"?

it would be useful if you could work with my code. Thanks!

@dharr understood, thanks.