@Alfred_F One way,

P := x^4 - 12*x - 12;
R := simplify([solve(P, x, explicit)]);
Pf := mul(x - u, u = R);
simplify(expand(Pf));

You may also compare against, say,
     simplify(evala([solve(P, x, explicit)]))
which has rationalized denominators.

@sand15 I did not state that picking off the coefficient for a particular power was some easily done from Horner form.

What I wrote is that one can easily have both forms at hand. Having both at hand, each could be used for that to which it is individually well suited.

Your demonstration of difficulty in picking off a coefficient of a given power from the Horner form is quite beside the point. It's obviously not a good thing to do. But your doing that ill-judged action, right between a quote from me and a snarky personal comment about me, implies that I suggested doing that mis-judged approach. But I did not write or imply any such thing.

Let me finish off the sentence that you only partially quoted: "...even if one also uses the Horner form for computing values."

I began my paragraph by stating that one could easily have multiple representations at hand. That means having them each, in the same session, all avaliable for different calculations and queries. The Vector form and the expanded polynomial form can easily be used for picking off coefficients of particular powers even if one also uses the Horner form for the quite different task of computing values of the dependent variable from concrete values of the independent variable.

I didn't write -- anywhere -- about using the Horner form for picking off coefficients corresponding to particular powers of the independent variable. I only wrote of (and showed) using it to compute values. That is (obviously, I think) values of the dependent variable.

You appear to have somehow misinterpreted my statements as meaning the opposite of what I meant and feel to be their clear meaning. I understand that we all of us misinterpret or mis-phrase, from time to time. (I could find several places on this site where I've admitted to such.)  But I have trouble understanding the descent into sarcasm and personal attack.

I've changed your query from being a Post to being a Question.

Could you not supply a worksheet in which a specific and explicit example of such an H, and all the ensuing difficulties and situtations your mention?

@sand15 

Since it's come up in a few other postings, if I may I'd like to make a minor note about that typeset wrapping: it's not doing anything here, and in particular it's not protecting against further evaluation. The same effect would be attained in this example by using just,
    legend=['phi'(x), 'Predictor'(x)]
instead of,
    legend=[typeset('phi'(x)), typeset('Predictor'(x))]

Protection against, say, subsequent assignment to name x and full evaluation of the plot structure, could be had by instead wrapping with InertForm:-Display or the like.

Also, it's extremely easy to have at hand -- at the same time in a session -- all of these: Vector of coefficients, explicit form, Horner form. Examining the coefficients (by index of the Vector, or from power in the explicit form) is still just as easily directly possible even if one also uses the Horner form for computing values.

@Andiguys You can use the plots:-textplot command for that, the syntax of which you've been shown before (eg. here) and which is documented on its help-page. You can also add new line calls alongside those, and put it in a rectangle.

Download Graph_legend_error_ac2.mw

Or, more tersely, and without so much cruft, and with a linebreak between the label of axis[1] and the caption,

Download Graph_legend_error_ac3.mw

Or, lower right, and tighter together,

Graph_legend_error_ac4.mw

nb. The legend structure is always rendered outside the plot body (beyond the axes), and not "directly inside the plot", as you requested. That's why I've done it with rectangle&line&textplot instead of legend and legendstyle.

@dharr The OP has asked before about getting the prime notation in pretty-printing of expressions used in plots. (Others have asked it or similar questions too, eg here, and others)

The same underlying issue (that the setting/level is not being respected during the mark-up) affects titles, captions, textplots, labels, etc. Ie. anywhere that math can get marked up and displayed in a plot.

Your solution of InertForm:-Typeset (and another variant I've sometimes used of InertForm:-Display) has the benefits over Typesetting:-Typeset that:
1) it's a documented command
2) it doesn't have special-evaluation rules (and so directly handles this example in which the formula has been assigned to a name)

I'm going to submit a bug report against this somewhat long-standing issue.

@WD0HHU As was visible in the output shown in my Answer, I used Maple 2024.2.

I might have time to look at Maple 2025... later.

@WD0HHU Notice the Maple version in my posting. If your version is different then it's only helpful if you tell us what it is.

@Gabriel Barcellos It is not explicitly stated in the original Question that the problem deals with a physical situation. It may well be true, and there may hints to that effect, but it was not overt.

Thank you for the clarification.

There were a few places where the simplification process needed some extra hand-holding (...for my line, sometimes to prevent it from undoing/overdoing some step I wanted...).

But, yes, often calling simplify (possibly after evala/radnormal/evalc...) on the difference is a good way to start. It's much more robust to turn the difference into zero than it is to "simplify" both expression to the very same form (which might not be "canonical" or obvious as the common target).

In this example the assumptions of the parameters being real is also part of what Maple needs to make some of the intermediate conversions (even without extra hand-holding). Using the assuming facility is often very convenient for that.

@sand15 You wrote,

      replace T = A^N/2 * B^N/2 by (A*B)^N/2

but those are not mathematically equivalent, and that substitution is not valid in general. For example, at the point,
    N=1, beta=7*I, eta1=1, eta2=-I+1, gamma1=1, gamma2=1

You could guarantee it by, say, taking A and B as positive. Now, both A and B consist of 1 added to some exp calls. And so one way to ensure that A,B are positive is to take the parameters as real, so that all the arguments to the exp calls are purely real. So considering the parameters being being real is sufficient.

Also, those steps and reductions -- as well as the picking terms out structurally with op -- could be done more mathematically (ie. non-structural programmatic steps, all steps done explicitly, from start to finish, etc).

@Andiguys 

You've been shown how to put the numeric values for the parameters in a caption, in an Answer to another Question of yours made today. For fun I'll give yet another way to generate that, in the attached worksheet below.

Note also that you could simply change the option name caption to title here, and move them to the top. I'm not sure whether that will export to .png file ok in your Maple 2022.

Note that there are already simple textplots (for pi[m]^DS, etc) in the above answer and plots. I'm not sure whether you want to keep those.

The attachment has a few variants, with/without those previous simple textplots, with/without the previous legend items, etc.

You could also mark the regions with textplots similar to your current legend items (or instead of the legend if you'd prefer). You can do that by putting additional textplots inside additional rectangles. I showed you how to do that kind of thing in an Answer to your Question of 21/01/2026.

Q1_3_ac_3.mw

All the items,

With the previous legend items and simple textplot region-labels,



ps. You can also pass option captionfont (or titlefont if using title) if you want it bold, etc.

pps. If those aren't the exact "labels" you had in mind for then it's because you haven't stated clearly what you wanted them to be.

Just an FYI, for those interested:

Some years ago I found out that the plotting substructure such as THICKNESS(0.1), with a positive float value less than 1, would cause the GUI to render a line thinner than it would for THICKNESS(0).

At that time pretty much no plotting command would do anything with a supplied option such as, say, thickness=0.1 except  to turn it into the suboptimal THICKNESS(0).

These days some commands (such as plot) will handle an option thickness=0.1 and construct the expected, matching substructure. But there are some commands which still may not, eg. DrawGraph. But the good news is that one can still supply thickness=0 and then substitute a replacement into the structure, as I did in my Answer below.

pl_thick_note.mw

@Mister_Matthew_abc If you can still access the email address linked to your older Mapleprimes account then you ought to be able to reset the password associated with it (sent as a link via email, from the login page, say)

The 5th bullet point of Description section the Help page ?procedure shows the syntax as being of the form,

   description descriptionSequence;

and the Parameters section of that Help-page explains descriptionSequence as a "sequence of strings describing the procedure".

A terminating semicolon is shown in the syntax. The word description is shown in lowercase. The fact that descriptionSequence can be a sequence of one or more strings is mentioned, and a string in Maple is documented by being wrapped in double-quotes.

Maple is a case-sensitive language. Sometimes case is used to distinguish functionality and purpose, eg. int versus Int. Alongside that, having other command names (such as Describe) be accepted case-insensitively would be a generally confusing.

The following example shows that, in both 2D and 1D input modes, the elements of the sequence may each be a string or a name.

Download description_01.mw

So it might be an improvement to document that a terminator is mandatory for each of the optional clauses.
nb.The following may not be valid syntax, despite being unambiguous,

proc(x) description "hey now" end proc;
Error, reserved word `end` unexpected

It might be an improvement to document that the elements of the description sequence may each be strings or names.

@WD0HHU I will repeat some of my points, to address your Reply. Wording is important to understanding the cause of problems.

Explore assemblies looks clunky in part because the Embedded Components and the GUI layout elements (eg. Table) are a bit clunky.

The Explore Library command constructs from those, and the GUI inserts and renders them.

That GUI rendering (alone) dictates the font of the tick marks on a Slider, and their font size, which are the aspects you mentioned. There are additional EC issues, like cross-platform appearance, Slider selection granularity, and (some) key aspects of the Table layout, and others.