@mmiller15 It has been 2-1/2 days since you posted. What's happening? I'd at least like to know whether my code is working for you. 

@maple2015 Messages about output-length limits are not errors. The result has been fully computed and can be assigned to a variable or otherwise manipulated. The message is there to warn you that you may not want the result prettyprinted on your screen. The result can be viewed in plaintext by lprint(%).

@mmiller15 To use my new code, called NCReduce (for Non-Commutative):

1. Download the worksheet NCReduce.mw from the post above. If you've already downloaded it, please do so again, because I just updated it.
2. The code is in a window in the worksheet called a Code Edit Region. The location of this window will probably be obvious when you open the worksheet. It's the only subwindow of the worksheet, and it appears with plaintext multicolored Maple code.
3. Click in the window, and then right-click to bring up the context menu. Select "Execute Code".
4. Immediately after the window, there should appear a message indicating that the default noncommutative algebra (what we have already discussed here) has been loaded. Specifically, the non-commuting symbols are u, v, w (with that being the preferred order), and the 6 transformations are Vu, vU, Wu, etc.
5. The package has now declared these symbols as non-commutative prefixes to the Physics package, and it knows the names of the 6 transformations, and it knows which transformations correspond to which pairs of symbols; but it has done nothing else. So now you need to load Physics and do exactly what you've already been doing, except that declaring the noncommutative symbols to Physics:-Setup is optional. Specifically, you need to enter the code of the 6 transformations (exactly as you've already been doing).
6. Set up your algebraic expressions exactly as you've already been doing.
7. To apply the package to an expression e, simply give the command NCReduce(e).
8. In addition to the reduced expression, there should be a message about the "Orbit length". If the code got to a point where (it thinks that) no more simplification is possible then the orbit length is 1. If the length is more than 1, that means that an infinite simplification loop has been detected with that length. (For example, if e1 simplifies to e2 and e2 simplifies to e1, then the orbit length is 2.) In that case, the first expression which is an exact duplicate of an earlier expression is returned.
9. These messages can be turned off if desired. In any case, these messages are not part of the procedure's return value. They are only displayed as side effects.
10. It's possible to do the setting up in steps 5 and 6 before loading NCReduce if you want. You just need to remove the restart command that's the first line in the Code Edit Region (not the restart that's the first line of the whole worksheet).

You also asked if it's possible to modify the old code to do this. No, I don't think so, because of the problem that you already pointed out. That problem shows that the algorithm needs to be fundamentally different. And, coincidentally, I already incorporated that difference without directly being aware of the need for it.

So why aren't you giving me expressions and transformations to test this on?

@mmiller15 Okay, I understand the problem that you were having with

VuReduce(v[0]²v[1]u[0]).

The problem is already fixed in the new code. The problem was that since the first pass doesn't move the first v (since it's not followed by a u), subsequent passes continue to only see that first v. The new code scans every multiplicand in every term on every pass.

@mmiller15 I just finished a package for this. It's generalized and extensible. It's built on the idea that the variables are wanted to be put into a certain order within each term---an idea that I got from one of your posts last night. I also added code to detect and break out of cycles, an idea that I mentioned yesterday.

This new code makes it easy to have any number of non-commuting symbols, and to change them, their transformer procedures, and their desired order at will.

The code is in the Code Edit Region of the attached worksheet. (To load code from a Code Edit Region, right-click in the region and select Execute Code.) I have not tested it yet because it'd be easier if you gave me some test cases. So please post your 6 transforming procedures and some test cases. The code is over 100 lines and I've used some new features of Maple 2018 that I've never used before, so it'd probably be better if I tested it, which'll only take about 15 minutes from when you post the test cases. And, as I mentioned before, this is the first time that I've used the Physics package.

NCReduce.mw

Regarding your problematic case that you just posted, or any other problems: If you want me to diagnose it, then you'll need to post a worksheet showing it!

@acer Oh, yeah, you're right. I was just judging from the way it was displayed in the post.

Anyway, if you do want it to display vertically, that can be done with display(< P1, P2 >). I can always remember the orientation when it's done in angle-bracket notation.

@Adri van der Meer

Vote up.

If you change the last line to

display(< P1 | P2 >);

then you can get side-by-side plots.

@mmiller15 Yes, it's possible, and I'm working on it.

Since v[a]^c*u[b]^d = Vu(a,b,c)*u[b]^(d-1) = v[a]^(c-1)*vU(a,b,d) for all c,d >= 1, why not combine
Vu and vU into a single procedure, VU, defined as
VU:= (a,b,c,d)-> v[a]^(c-1)*vU(a,b,d)
or
VU:= (a,b,c,d)-> Vu(a,b,c)*u[b]^(d-1) ? I think that those two must be equal if your system is consistent. Thus, you only need 3 procedures, not 6. Am I missing something?

@mmiller15 Do you want to always apply all 6 transformations at once? Or do you want to be able to specify which of them to apply?

Your use of map in this case is superfluous and quite confusing to the reader. The command

map(f, (q-> ...), e)

is always equivalent to simply

f((q-> ...), e).

This is because a procedure or arrow expression such as q-> ... is not something that can be "mapped over". (In Maple-speak, such an expression is called atomic.)

@ecterrab Yes, I see it now: The `@@` expression is in prefix form. My reading of it was hampered because the backquotes that usually signal a prefix-form operator do not appear in the prettyprinted form of the expression.

@ecterrab Your solution contains a subexpression of the form

(t^n)@@(U-> ...).

I am of course familiar with F@@n where F is a procedure and n is an integer. What does it mean when F is algebraic and n is a procedure?

This'll be easy to do with a single evalindets command. I'll show you how to do it, but I need more information first.

1. What are the allowed values of c? Do they include 0? negatives?

2. Are subscripted variables formed as v[a] or v__a? If you don't know, then look at them with lprint to figure it out.

3. You mentioned non-commutativity. What do you do to distinguish v[a]*u[b] from u[b]*v[a], which Maple considers identical expressions?

4. Should v[a]^c*u[b]^d be treated as (v[a]^c*u[b])*u[b]^(d-1) = Vu(a,b,c)*u[b]^(d-1)?

@vv Sorry, I did not intend any offense. I simply thought that you were claiming that it was necessary to perform these computations at huge values of Digits in order to obtain a result accurate to some small number of digits.

It has always been a serious deficiency of fsolve that one can't set the number of "guard digits" as one can with RootFinding:-Analytic, RootFinding:-NextZero, and `evalf/int`. Thus fsolve guesses at a number of guard digits to use. It insists that its returned result be accurate to Digits. The end result is that there are problems for which the values of Digits for which it converges are essentially random.

Another command with the same problem is `evalf/sum`.

@vv I may have overlooked it, but I fail to see the part of this thread where anyone other than you actually wants a result accurate to 5000 digits. Rather, it seems to me that some have claimed that it's necessary to use a ridiculously large value of Digits (like 5000) to compute a result accurate to some reasonable number of digits, like 20.