@mmcdara It seems possible to replace (by a1..a8) all the names in ra[1] except eta, gamma, and phi (noting that phi does not even appear in the rhs's of the equations).

The result is somewhat unwieldy, though.

How are those Tables of outputs constructed? Are they inserted Tasks? Could you provide a version of your worksheet in which the underlying Task(s) or construction mechanism is shown?

The OP's followup example showed that he didn't want  1/`%+`(k,7)  which is the inert form for k+7.  Carl's already pointed out that OP's inconsistency in requests.

So I've redone my followup Replies to show either a fully active expression, or one where the user can utilize either a partially or fully inert/active form.

Now also for Product.

And for an infinite bound.

Hopefully without too many mistakes.

Download ts_multi_sum_5.mw

@Carl Love Some months ago, the order of Answers-with-equal-votes changed from the historically longstanding oldest on top to (ugh) newest on top.

Christopher might not have noticed that change in behavior. When you originally answered, after me, your Answer was on top of mine.

My requests to get this new and confusing behavior reverted have not had success.

And now using `%+` instead of replacing Sum by sum, because I just realized that it would allow be to enter the expression without inert operators.

After writing this, I see that it's getting close to Carl's approach. (I hadn't noticed his use of `%+` for inertly adding the terms. I confess that I didn't read it carefully enough, sorry, even though I saw that he'd mentioned not needing the expression entered by the user with inert operators. I guess I missed the point.)

This is a pretty simple procedure, but can handle several kinds of example and is flexible because the particular aspects/level of inertness can be specified in the input.

Download ts_multi_sum_4.mw

The OP's second (followup) example, using my second approach in my Answer:

I did command-completion on Sum, to get it as the 2D Input with inert gray Sigma. But you could also just type the argument in text code, eg. Sum(`%/`(1,k+7),k=-2..3)

Download ts_multi_sum_3.mw

ps. It's more useful to tell us what other kinds of example you want handled, and exactly how, up front.

The GUI adds extra space so that you can rotate the cube without parts of it going out-of-view (ie. beyond the inlined plotting window).

You can manually right-click on the plot and zoom into it a little, to make the cube occupy more of the inlined plotting window. (You can also get such a effect programatically, with a bit of effort. But I'm not sure how that survives exporting to animated .gif file, if that's an end-goal).

@Ronan How would delayed-evaluation quotes help if the Matrices were originally returned by some other computations?

What would you do in that rather common scenario? (I can think of some way, but it seems a bit exotic.)

@Andiguys You have mistakenly entered some expressions as function calls instead of as products (multiplication).

In particular you've forgotten to enter a multiplication symbol (or space in 2D Input, to denote multiplication implicitly) between the name varphi and opening round bracket, when you construct the expression assigned to A.

That mistake in syntax causes all the following function calls to appear in ineq1 and ineq2.

   Pu(-2*U*upsilon+1), a(-2*U*upsilon+1), beta(-2*U*upsilon+1),
   p1(-2*U*upsilon+1), t(-2*U*upsilon+1), upsilon(-2*U*upsilon+1),
   varphi(-2*U*upsilon+1)

In the statement that assigns to A, you could add a `*` multiplication symbol (in any input mode) between the leading name varphi and the opening round bracket, or (if in 2D Input mode) you could add a space to denote the multiplication implicitly.

That should cover you syntax mistake, which is why you got those error messages.

But your solve calls might not work well or fast.

Btw, I see that in your last attachment you're not using the technique I showed you before, where you can move terms with/without p1 to the two sides of the inequality, prior to calling solve.

You know, if it's linear in p1 you don't even need to call solve, really; you could just form the piecewise solution according the the signum of the coefficient of p1 (ie. if negative then dividing by it flips the direction of the inequality).

What do you intend to do with the resulting expressions (created in this iterative manner)?

If they will all be functions of x (given numeric values for the parameters), how will they get used?

What will be the final range of x used? Is a purely numeric process allowed? By that I mean that, instead of a sequence of expressions in x, could you instead use a sequence of black-box procedures that evaluated (at any given x value) to similar values?

I ask because even with rationals-replacing-floats, the expressions may get large and (not just unwieldy but) perhaps also prone to excessive numeric error when evaluated at numeric x values. It's possible (maybe) that you might have to mitigate that.

@salim-barzani There were extra negative signs throughout; which were not technically wrong but was unnecessarily confusing. What I did was not just about the signs; I just mentioned that as an aside. That's not the main part of what I did.

But the formula for Q[i] are indeed wrong (either in your worksheet or in the paper), in the sense that the entries in your summation don't match the formula in the paper. That's how the lack of agreement in between your A[i] and the paper's A[i] comes about. This is the main point of my last worksheet. See my switch to,
   diff(conjugate(U[k](x,t),x))
in the B1[n] formula.

I also got rid of the generated Transformations equations, because they are clutter. But, like the signs, that was just tidying.

ps. As a sanity check it might be worthwhile trying without Physics,diff loaded. That causes the conjugate products to be put into even more ugly abs&signum form. But that can be converted back to conjugates (though it takes a few more calls to force that...) When I tried I got mostly the same as before, ie. still a disagreement in at least one term in u[0],u[1],u[2]. I am not yet convinced 100% that the paper is completely right. Do you know that it is?

Oh, yeah, another sanity check would be to change the Sigma summations into add calls, to ensure that no symbolic summation weirdness occurs.

@salim-barzani I've tidied up the negation signs, etc.

And I replaced that somewhat awkward Transformations code that turned the unwanted abs calls into products with conjugates. You can do that all instead with a convert call; you don't need to form all those relacement equations.

I've also notced what might be a mistake in your worksheet's summation for the Q[i] ( ie. B1[i] ). Changing it gets the Ad[0] and Ad[1] much closer to what's in the paper (though one addend term still disagrees.)

You should double check it all.

Download b1_ac3.mw

@salim-barzani The formulas for the Ad[i] do not agree with those in the paper.

Also, the methodology for substituting for the U[i](x,t) is very fragile and shaky. And the whole substitution code is awkward enough that you cannot go back to redo earlier lines, due to the ill-advised assignments and replacements of U[i](x,t) with u[i], et, etc.

So I've attempted to make the process more robust, in those regards.

And now a problem can be noticed: the Ad[i] do not match the formulas in the paper(!). If I manually adjust the first few of them, to agree, then the u[0],u[1],u[2] can be obtained which agree with what the paper got.

So now you have to figure out whose A[i] formulas are wrongly computed: yours, or the papers. You'll have to study the P,Q,R. (I don't have time, right now...)

Download b1_acc.mw

@salim-barzani If delete this one too, after I work on it, then I doubt I'd look at your future Questions.