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

There's something goofy going on witheven the u[1] and u[0]. I can look later this evening.

The change from exp to sin,cos happens because of your evalc call. It's easy to amend that.

But the key will be to fix the appriach so that even the first a[1] comes out as you expect...

@salim-barzani Why didn't you show the expected result when you posted this Question thread!?

Or, were the additional details in one of your earlier Question threads that you've deleted?

@Geoff That's a regression in behaviour; Maple 2024.2 gets it in one call to simplify.

You can report bugs at this link, btw.

@emendes It returns the expression with the subexpression (addend) z*x becoming x*z, which is what you asked for if I'm not misunderstanding.

See the comments (after # symbols) in the latter code. See also the 3rd paragraph in my previous Reply. By sorting z*x into x*z anywhere -- including on its own -- it becomes thus sorted everywhere it appears structurally. Instances where it appears structurally merely point at the unique stored item. The sort command can actually change that stored item, in-place.

If the stored item is x*z and you type in, say, cos(z*x) then that automatically becomes cos(x*z) because z*x is uniquified (automatically simplified) to the stored x*z. And case of the opposite order being the one that happens to be store would also hold. For this example, it's one order of the product, or the other, that happens to be stored.

So the nature of the sole stored representation of the symbolic product of (only) x and z then rules over previously created as well as new expressions that contain it structurally. NB. p*x*z doesn't contain x*z structurally (even though it may, mathematically).

Download uniquification.mw

The mechanism for centrally storing items helps Maple performance. See also "The Simplification Table" in Appendix 1 of the Programming Guide.

The background knowledge and explanation is advanced Maple. But usage (like we're doing here) can be quite practical.

@nm I deleted the other Question thread.

If you are going to post multiple examples involving recursion errors during odetest (including while using Physics 'assumingusesAssume'=true), and if you also suspect that they might be related, and if you also are going to reference any of those from another in words, then they are closely related.

I have asked before, politely, to please either cross-reference such queries with links added manually, or to get such links automatically added by using the Branch button on a Question, or to simply group them together in the same Question thread. It's a reasonable request, because otherwise it's unjustifiably difficult for people to properly follow all what you are saying (especially at some future date) on this topic.

Ideally everyone here would be respectful, and honest, and helpful, whenever possible. In the absence of that, maybe I ought to stay away.

@rlewis You've changed the example I gave from using the plottools:-polygon command to using the plots:-polygonplot3d command, and kept all the other syntax corrections. The result is essentially the same, here.

It's good that you have it working.

@emendes Is this the kind of fix-up you're after? That is changing z*x back to x*z.

I added it as a late step in the Alt_monomialsGB procedure, but at the end of this worksheet I also show how you can apply it to an arbitrary list of expressions (of type polynom in your list of names). You could even make that a new small procedure.

The basic idea is that it simply forces re-ordering of the multiplicands in (only) the subexpressions of type `*`. Maple stores a single instance of such terms, in a special internal structure, and sort acts in-place on those; the sorted instance then appears (automatically) in any expression containing those terms.

Download more_sort_fun2.mw

@emendes Yes, that's an artefact of some of the forced sorting orders.

As I mentioned in the initial text of my original Answer, that (somewhat cosmetic) effect can be adjusted by an additional `sort` applied separately to the individual terms. I can add that, maybe tonight.

Do you always want the individual product terms alwats to have their multiplicands in usual alphabetic/lexicographic order?