Put your revised integral here, either in the Question body as attachment or in a Reply/Comment.

A duplicate Question thread is unhelpful and unnecessary and will be flagged as a duplicate (which may be deleted).

@emendes Please explain why your solution excluding both alpha[2,3] and alpha[3,5] is optimal or best. Earlier, you wrote, "reduce as much as possible". What if you could exclude just a single variable, would that be better still?

Are you trying to find a minimal set of equations, or unconflicted variables? How do you break ties?

Provide a rigorous definition of what you want.

Please explain all these points clearly, and not just a partial or incomplete answer to one of them. (It's not really enough to see you agree with someone else's suggestion. At this point you really need to state precisely what it is that you want.)

@Carl Love Taking his followup example, with the equations in a list eqns in the order written, I don't see whether he might be asking for, say,

   eqns[1,2,3,4,5,6,7,8,9,10]
or,
   eqns[1,2,3,4,6,7,8,9,10,11]
or,
   eqns[1,2,3,4,6,7,8,9,10]

And, for general examples, I don't really see how he is specifying any choice that can arise (in equations or variables to omit).
   

You appear to be using square brackets as some kind of expression delimiter for grouping terms arithmetically, which is incorrect. You need to use round brackets for that. Square brackets denote lists.

@emendes I'm not sure what you're trying to ask as followup.

The subset  eqns[[3,4,5,7,11]] of the equations (where they are defined in a list as below) are inconsistent.

You might consider omitting either eqns[5] or eqns[11]. But otherwise I don't see how you want to resolve the contradiction (which can be expressed in terms of the value for a[2,2] alone, perhaps).

Download poly_hmm.mw

I'm not saying that what you're trying to do now is necessarily impossible, but rather that I don't really understand what you are trying to do here.

@escorpsy Nontrivial values for J and g may not be required, but thanks. I mentioned convergence because -- after having taken a look -- the opposite seemed to hold.

It seems that another member agrees.

@escorpsy If you collect the expression in [J,g] then (it seems to me) that you can obtain integrals that contain only Zeta (the integration variable) and no other indeterminate parameters.

Are those (separated) integrals convergent? Do you have anything to say about J and g?

Your worksheet assigns a numeric value to varepsilon,  but the expression assigned to W contains ln(epsilon) and no instance of varepsilon.

Perhaps this was a mistake, and you intended to assign to the name that you used?

You have used Lambda in a multiplication, Lambda*N*P, like a simple name. But you've also used it in function call, Lambda(1-p) . Perhaps you intended the latter to be Lambda*(1-p) instead?

Do you already know that gamma and I have special predefined meanings in Maple. You should declare them local before trying to compute with them as mere names in general (or utilize different names in your formulas).

@Vrighty If you are typing in the expression in x from scratch then you can do this to obtain a procedure:

  f := x -> 5 + x;
  f(5);

If the expression comes as the result of another calculation (say, the result of calling procedure blah, or solve, etc) then you can use unapply to obtain a procedure. You cannot use the arrow notation directly in this case and have it all work properly.

   f := unapply(blah(x),x);
   f(5);

You cannot use the syntax f(x):=... and get it all to work properly, regardless of whether you start entering all the expressions by hand or if they arise as the results of computations.

Or you could use an expression and 2-argument eval (as I alluded to earlier):

  f := 5+x;
  eval(f, x=5);
You just wrote, "In the past, I have... Everything works just fine. I expected, if I do the same, I will get the same result...".  The problem is that the worksheet makes syntax mistake after another. It is almost all done completely wrong. There are even parts which work because two later mistakes just happen to accomodate a prior one. But eventually it all tumbles down and becomes unworkable. It is riddled with statements like this, which are having effects,
   F(x) := F(x);
...
   F(k) := F[k];
...
   F(x) := subs(x=y+c,F(x));

Procedures are created but then only ever used by calling them with their named parameter, which makes many more steps or much more complicated syntax than needed.

The best solution is to rip it all out and start again using only expressions. A smaller amount of corrections that will allow you to proceed along your path without it all becoming unworkable is as I suggested in my posted edits. (You could get rid of the initial unapply calls where expressions are first defined, yes. But you have to either use unapply or expressions and eval throughout, for the many instances of the other cases, and you cannot work it practically with the mis-used remember table assignments and indexed references.)

The posted document is one of the most muddled I've ever seen. That's OK, we all had to learn somewhere. But I find your resistance to suggestion alarming, given the severity of the muddle.

I cannot for the life of me understand why at least two people up-voted the question.

I changed a recent submission by you from Post to Question. Please don't submit usage queries as Posts. (But that one wasn't a draft -- it had already been submitted, albeit incorrectly.)

You should be able to see tabs/links that point to all your Questions/Posts/Replies.

@dingtianlidi Hmm. Perhaps it is a bug. You could ask support@maplesoft.com

You have not told us explicitly which version of Maple nor which Operating System you are using.

On my Maple 2019 for Linux the user-defined Tasks get put in a Help Database file like
    ~/.maple/2019/tasks.help
Perhaps on your OS there is a similar file. Eg, on MS-Windows it might be under either C:/Users/yourID or wherever kernelopts(homedir) reports.

Have you tried using the command DocumentTools:-RemovePaletteEntry ?

@Carl Love This site is running an old and outdated version of MapleNet as on its back-end server.

I have requested -- several times over many years -- that this site's back-end server be updated, in particular for this gridlines problem (which was purportedly fixed in more modern MapleNet, in consequence of one of my reports long ago).

I've also asked that the inlining of .mw worksheets use a better graphic export for plots than JPEG, which is why inlined plots look so poor. Any update should utilize PNG export (though even GIF would look much better than present).

Over the years I've sometimes asked nicely and I've sometimes asked brusquely -- that doesn't seem to make a practical difference.

@kfli You said that you run that code a "bazillion times".

But presumably you don't run all that code many times, since you've included the call to Compiler:-Compile. So, I suppose you call cProduct_3DC many times. I asked earlier how that has to be done, and I suspect that still matters. Is there a reason that you cannot supply complete code to reproduce, or at least code that calls Product_3DC several times?

Could you supply a summation formula and description for what Product_3DC does?