@vv That's nice, short, and easily understandable. (vote up, naturally)

In Maple 2025.0, without the factor@expand,

> kernelopts(version);
   Maple 2025.0, X86 64 LINUX, Mar 24 2025, Build ID 1909157

> A := -x*(x - 4*exp(x/2) + 2):
> B := x*sqrt((-8*x - 16)*exp(x/2) + x^2 + 4*x + 16*exp(x) + 4):

> simplify(eval(A-B,x=2*t)) assuming t::real;

                0

In Maple 2024.2 it doesn't need the substitution,

Download nm_simp_ex.mw

@nm Why not consider it a sympy weakness?

What does that O(..) term represent there? Is it so useful, that its presence/absence might not be used for some addititional programmatic leverage?

Please put your queries in a "Question", rather than a "Post", in future.

I've changed this one to a "Question", for you.

ps. Yesterday you submitted two Posts for it, concurrently, with the exact same content, before any moderator touched either. There's no need for that.

@zenterix You had several flavours of plot call. If you run into issues for any of them then you can come back to this, and force it with these options.

@segfault When my Java GUI locks up, and it won't close down using its window's corner icons, then I kill the parent java process in my OS.

That usually also kills its child mserver processes, but if not then I kill those afterwards

ps. Since I sometimes run multiple worksheets (some of which I really don't want to die if any other worksheet freezes the GUI) I use an option to allow wholly separate Java virtual engines. I do this by adding    -standalone   after the executable call string in the Properties of the desktop icon that can launch the Maple GUI.

@segfault If I change the color and font of "Maple Input", then Ctrl-j inserts a new Execution Group that respects those choices.

And if I save that choice for an empty .mw worksheet file, and set it for "Open worksheet at startup", then each new worksheet (File->New) also gets those choices for "Maple Input", including in new Exec Groups inserted using Ctrl-j.

It also gets the modified style choices if I use F3 to split (or get a new Exec Grp below, if focus is at the end of the current Grp).

I didn't have to manage "Style Sets" (per se) to get that working. I just modified "Maple Input" (via "Format", from the menubar), removed all content of the sheet, the saved the empty .mw file and made it the default start-sheet.

It's unfortunate you can't get that working; perhaps you have bad luck. Can you not upload and attach your custom empty/template start-sheet here?

@segfault Your original Question text is not clear about whether you wanted only to change the Input from black 2-D Math to plaintext reddish Maple Notation, or whether you also wanted a custom font family and input color.

If you want to adjust the color (Burgundy to Red, say), or to use a different named font, then you can create a Style Set for that. See the link in my Answer.

You can also create an empty Worksheet that uses your custom Style Set, and then make that the default (unnamed) sheet that appears when you do File->New to open another. See the menubar item,
    Tools->Options->Interface->Open worksheet at startup
and set it to your empty (template) worksheet that has the Style Set you want. (You might also be able to put it on a customized Start Page, but that doesn't seem simplest.)

In the original Question the OP mentioned simplify only a a failed way to get the desired sub-term sorting effect. as I read it. (I didn't originally interpret that as a request to also factor or simplify.)

But here that is, with some factoring as a preliminary step:

Download Format_odes_acc2.mw

note: Here, I omitted assigning the result from F (which sorts the subterms) to yet another name, just to show that the effect on new is in-place,

Some more natural attempts at the preliminary step of such factoring can sometimes run amok of automatic simplification getting in the way (eg. if one tried collect(...,[..lambda__ij's..],..) say). That relates to what the OP has noted about automatic simplification happening on 2*(a+b) but not on 2*(a+b)*c say.

ps. I didn't need to utilize ``(...) specifically in the preliminary stage. I could have chosen something else, like __K(...) in its stead, as the way to temporarily wrap the content(u) and avoid immediate automatic simpliciation. I only chose ``(...) because it can be fun/insightful to see the intermediate expression before that's removed with the eval call. As it happens that preliminary factoring&simplification could also be done for this example with,

   collect(lhs~(-~odes),[diff],u->content(u)*simplify(u/content(u)))=~0;

But, as mentioned, you sometimes have to be careful with the last action in a collect call, due to automatic simplication.

Lastly, I'm confident you've realized that the following would happen, also due to automatic simplification.

So far I haven't used any inert representation to get a rendered formatting to avoid that; My previous answers have produced expressions that print as they are. But here's a variant that pulls out the common factors of 2, and represents it inertly, in a couple of ways,

Download Format_odes_acc2b.mw

@C_R For L a list, the call,

    map(print, L)

will return a list whose entries come from all the return values of the print command. The print comnand causes the interface to render as a side-effect, while its programmatic return value is NULL. So the return value of that mapped call is an empty list. That's why I usually write such a call as,

     map(print, L):

with a full colon statement terminator to suppress the printing of (only) the return value.

Did you have a particular kind of f(x) in mind?

I don't mean so that we could just show a 2D plotting call, because I know that you know how to do that well. I mean so that we could check against any FunctionAdvisor attempt.

@NIMA112 You have non-function-call terms with omega, such as,

    omega * (x + xi)

and,

    omega * abs(x - xi)

as well as terms with function calls, such as,

    cos(omega(y + eta))

and,

    D(omega)(y + y__0)

What did you intend for all of those to mean, taken together?

Try attaching a renamed version of the worksheet .mw file, without the "&" character.

@jasser 

Do you want all possible sums >=  maxsum, or all the combinations whose sum = maxsum?

I only ask because you haven't commented on that aspect in what mmcdara has shown, checking against the strict equality (so that all the returned lists have sum=N).

Also, how many elements might be in your "longer lists"? And how fast do you need it?

Do you need the results separate, for the various odd q values? Or is it ok to do them all at once?

@C_R In the above, the Equation Label is acting similarly to the case where the input was written literally, as opposed to the case of being the value of an assigned name.

That might be the correct behavior of evaluation for the Equation Label's insertion. When I say "correct" I mean that having an inserted Eq.Label behave like an assigned name might have other kinds of problems. Certainly Eq.Labels have had evauation issues -- and tweaks/fixes -- over the years. I would believe it if a kernel expert told me that Equation Labels ought to act exactly like literal input.

The second and third add examples in my worksheet above both throw the same error if the sequence has four or more elements. In that case they both still don't work similarly to the case of an assigned variable. Using a list still handles that case fine. add_seq_ex2b.mw

So examples 2&3 don't act like examples 1&4, whether the sequence has three elements or more. That aspect, which was my main point, remains just the same as before.

I originally chose a sequence of three elements simply because the call to add using the literal sequence as arguments (third example above) happens to (kinda, sort of) match an esoteric add call with a skip/step value, and so produces no error message. The absence of an emitted error means that a user is less likely to notice the wrong&unintended result.

ps. I deliberately put in the Equation Label example because I know that you use such.

@C_R I'll make another comparison, if I may.

The last three calls below (ie. wrapping in a list) form an approach that works consistently, and has no unexpected "gotcha" pitfalls.

That approach, to pass in a list, also happens to guard against your case of a single scalar (product, say).

Download add_seq_ex2.mw