@C_R Some of the internals of dsolve utilize remember tables or a cache, which avoids duplicate re-computation if the call to the command is repeated.

Some of that affects some of the userinfo messages (since some of those userinfo calls are made underneath such an internal entry point).

Note that your Document doesn't begin with a restart, so if you re-run it without restarting via the ribbon then some or the computations are memoized.

@C_R 

• open https://www.mapleprimes.com/view.aspx?sf=243654_question/repeated_equation_labels.mw
• insert a new document block after DEtools:-odeadvisor(ode[1])
• cut/paste DEtools:-odeadvisor(ode[1]) into new document block
• either execute the whole worksheet from its beginning using the !!! from the Home tab in the ribbon,
  or Remove Output from Worksheet and then execute it from the start line-by-line

with Maple 2025 and 2026 performed

repeated_equation_labels_-_after_moving_odeadvisor_command.mw

Executing the two statements in the 1st Exec Group in the problematic Document Block, before removing the 2nd Exec Group doesn't seem like an effort to avoid the problem. It's not something that I suggested in my earlier response.

And we already knew how to reproduce the problem! Just execute the original, without cut&pasting anything! Showing another way to reproduce the problem (which happens to only kinda/sorta/almost look something hazily like what I actually suggested) really isn't a highly meaningful response to my suggestion of that it can in fact be avoided. Since I didn't suggest your particular steps, they don't contradict that my suggestion -- if done as I did it -- avoids the issue. There are milllions of small edits of your original that will also behave the same as your original; they don't add too much value here.

@C_R Could you attach (but not inline) that edit? Thanks.

@C_R [The text has since been edited, to clarify the goal.]

This new Question thread duplicates the essential topic of an earlier Question, and is posted as a wholly separate new Question thread. It would have been better to utilize the "Branch" button off of the original Question, so that this would branch off the original and both Questions would automatically get cross-reference links.

[edited]

The Question text has been edited. The original language suggested a desire to demonstrate that two expressions match, which I interpreted as a desire to demonstrate mathematical equivalence.

The new language suggests, rather, a desire for transformation from one given form into another specific form. And, naturally, that's fine as a goal. (It just happens to be different that the original suggested.)

@janhardo It's unclear what you're trying to say.

P is a factored product. That's central here. The query hinged on the interpretation of the ellipsis.

The f[i] can be sums (polynomials), but that's not central to the query.

Is this old posting of interest to you?

Just to be clear, that P formula represents a product of terms (and not a sequence).

@dharr I like this approach, as a heuristic, and often try it.

One idea is that evala, trying to get some kind normal/canonical/standard form, will try to rationalize radicals which are explicit multiplicative factors of the denominator.

So if you have a target form that has, say, a numerator which is just some integer, and a denominator which is a product of radicals, then it seems reasonable that simplifcation of the rationalized reciprocal might be a fruitful approach.

A couple of variants on that theme, which also happen to work here. (The last one is lower strength.)

Download Simplify_radical_02_acc.mw

While I often try this as a stage in attacking some problematic example, I find it a little harder to explain, since on the surface it might seem a bit ad hoc to some users.

@C_R If I recall correctly, member nm once showed some experiments with a procedure that would attempt simplification using [at that time, a single call to] a variety of commands such as simplify, evala, combine, evalc, etc.

Many years before that I had a more involved utility which did a similar kind of task, but recursively (using multiple command calls), in quite a sophisticated manner. It had various bells&whistles options to allow specification of recursion depth, time-limit, actions to include/exclude, choice of metric to use, extra manipulations like collect, actions-spilt-across-numer/denom, expand, double reciprocation, split action across summads/multiplicads, custom metrics, etc. It would return the command sequence(s) that could attain the most compact form found.

Eg,
     collect( expr, [a, x], u->simplify(factor(u),size) )
or what have you.

It could sometimes reveal very nice results. I called it crush.

There was a sister utility, which could search for optimal trig expression rewrites (recursive combinations of half-angle, double-angle, sum-to-product, product-to-sum, pythagoras, etc) based on trying combinations of selected veiling of trig function instances in the expression. For example, there are expression for which veiling cos(x) (when all others of sin(x), sin(y), cos(y) are still present) can fortuitously lead to a most-compact form.

The first utility was often very useful, since it could often be used not to "out-do" simplify but also to obtain the action chain that would attain the result. The second utility was a more potemtially expensive solution (due to combinatoric selection from trig calls present), for a somewhat more niche topic.

I might have lost both after a couple of hard-drive crashes.

Apart from custom user-defined size metrics, it offered stock choices of MmaTranslator:-Mma:-LeafCount, and `simplify/size/size` (which simplify(...,size) can utilize), etc.

@WD0HHU Yes, susbindets & evalindets are very powerful.

They are made more useful by the scope and power of the type system. It is the second argument to subsindets/evalindets, ie. a type, which specifies which subexpressions to change.

Another tip: sometimes it's helpful to know (or test in advance) which subexpressions would be acted on by subindets. For that one can first call indets instead, giving it only the 1st and 2nd arguments. Ie, their syntax is usefully similar:

    indets( expr, the_type )
subsindets( expr, the_type, the_action )

So it can seem less confusing, to first pin down and figure out what the precise type ought to be, using just indets. Then, you can take just one of the returned subexpressions, and try and figure out when the desired transforming action ought to be. (You may have an action which greatly transforms the subexpressions.)

Figuring it out in these steps can be less confusing that trying to figure everything out at once with subsindets right away. Also, since the result is always an unordered set (rather than a list) it can sometimes be tricky to figure out the whole process that subsindets is doing since you may not know which element of the final set came from which subexpression.

@WD0HHU The direct result of your substitution is an expression that is unsimplified (and unexpanded).

You could apply one of the commands expand, normal, or simplify to that result, to get the explicit zero.

@nm In this case solve returns several solutions (as lists).

And here [solve(...)] is returning a list of lists.

So, here, you'd need to map your stated approach (which itself maps an operator).

And for a list of such lists of lists of equations, you'd need to map yet again at another layer...

I used subsindets because that single call handles all the equations in the whole expression list-of-lists, etc, directly, regardless of nesting depth. Not a map of a map of an action, or what have you.

It's not just that I don't want to have to type out any extra mapping layers. I'm also ok not having to need to think about it (as a single subsindets call suffices here).

@WD0HHU If you run the command,

   [solve(sys,explicit,allsolutions)]

on that system then the various solutions will contain many "trivial" items, such as a=a, or C[1]=C[1], or sigma=sigma, etc.

I find that those are somewhat distracting. So I apply the following to that list of solutions,

   subsindets( that_solution_list,
                       `=`,
                       eq->ifelse(eq,NULL,eq)
                      );

So, what does that do? If replaces with NULL any equation in that raw solve result whose rhs equals its lhs. A trivial equation like  lambda=lambda  has that property, and is one of those removed, ie. replaced by NULL. It's an equation, ie. of type `=`.  And under the evalb test which ifelse applies it returns true.

evalb( lambda=lambda ); # returns true, causing the next line:

ifelse( lambda=lambda, NULL, other ); # returns NULL

For example,

L := [a=b, c=c, d=e, f=f];

       L := [a = b, c = c, d = e, f = f]

subsindets( L, `=`, eq->ifelse(eq,NULL,eq) );

               [a = b, d = e]

So, the trivial identity equations are removed (replaced by NULL), and others are left untouched.

Hope that makes sense.

nb. The various solutions in that list [solve(...)] can be substituted into the original polynomial equations, to show that they really are solutions. But that can also be done with the shortened solutions (with the trivial items removed).

You could submit a Software Change Request (aka bug report) with those details, by filling out the form here.