@max125 Follow up details are useful.  You can add them as comment on the original, or as augmentation to the Question.

Keeping details in the same thread is more productive.

What platform (operating system) are you using. That information (along with Maple version, already here) can help.

Please don't post duplicates of this issue as separate Questions/Posts (with other names being help-queried).

Please be more specific about what effects you want here. Do you want a rescaling of the curve, or placement of the axis tickmarks or gridlines? Or both, or...?

@JAMET Could you upload a worksheet so that the intent is more clear?

@Anthrazit The various function calls in xmltree (to _XML_Element, etc) all have an attribute on them. The attribute is the name inert.

Attributes are not shown (usually) when you print a thing to output. See the Help page for attributes. For example, the values assigned to xmldoc and xmldocA are different, though they print the same.

The HasChild command seems to need that inert attribute, to work here.

The result from XMLDocument (or ParseString, and possibly ParseFile) has function calls which lack that attribute. So, unlike your original xmltree, the HasChild was not working as you wanted.

Hence I added a command that would recurse through the result from XMLDocument (or ParseString) and added the attribute to the function calls. And then HasChild worked as wanted on that modified structure.

@tomleslie That does not always work properly, eg. if the polynomial is not dense and lacks some term.

The problem is your use of coeffs. It is easily repaired. One may compare,

restart;
p := -31*x^5+7*x^4-23*x^2+94*x-48:

ListTools:-Reverse([coeffs(p)]);
                     [-48, 94, -23, 7, -31]

PolynomialTools:-CoefficientList(p,x);
                   [-48, 94, -23, 0, 7, -31]

[seq(coeff(p,x,i),i=0..degree(p,x))];
                   [-48, 94, -23, 0, 7, -31]

But it is quite fast (because the Matrix constructor and its scan=band[...] option scales poorly, sigh).

@nm The default is separate kernels for each sheet in a single GUI. If your setting was same/shared-engine then it must have been set that way at some point in time.

Btw, the -standalone option (for separate GUI jvms) is not documented. (I've mentioned it before on this site, though.)

There is some additional gain from -standalone, in that it will shield separate sessions from each other's GUI crashes. Another convenience is that you can open the very same .mw file more than once without having to rename it.

@Rouben Rostamian  Yes, the option -standalone works on MS-Windows as well as Linux.

Without that option then multiple/concurrent launches of the Maple Java GUI will cause the same jvm (java virtual machine) to be used.

The -standalone option makes the GUI instances run under separate jvm processes.

A significant effect of separate jvms is that a GUI crash in one can leave the other instances unaffected (if the host OS doesn't freeze, naturally).

You can add that -standalone option to the end of the target in the Desktop launcher icon's Properties. This is the first thing I do whenever I install a new Maple on Windows. (The option may also be passed into the bin scripts on Linux.)

Ten years ago the large initial footprint of the combined jvm & Maple GUI was significant relative to average total RAM size, and so using a shared jvm had nice resource savings. Now it is relatively a smaller portion.

@Tharoux What platform/operating-system are you on?

(Have you checked the tech support faqs, especially perhaps those related to java and posssibly OSX?)

@mapleatha Your partial fraction examples do not show an explicit reordering of terms in a particular sum, as you originally claimed. Which sum was reordered?

More importantly, how does a call to RTABLE affect it? Why leave out the crucial detail? Why not include that important aspect, within a (Maple 13, say)  .mw worksheet inlined in your Reply?

@mapleatha Of course I'm not saying that. I didn't say anything like that.

It's quite straightforward to reorder terms in a polynomial, using the `sort` command, for example.

That's the second time you've misrepresented me, this time dishonestly so.

What I did do is ask for a clear example of how using an RTABLE call would prevent the reordering (which would otherwise occur, as you mentioned). You still don't provide such an example, even though just one such example would help.

I have *not* denied that term reordering can occur. I can even force it in some ways. I've asked you (several times, politely) to show how RTABLE helps there, with a succinct but reproducible and complete example. It disingenuous of you to equate my request with a denial of existence. I wanted to see *how* it worked, so that I could understand what was working before.

I was hoping to help. Alas, no more.

@mapleatha It was not I who suggested that you might have assigned something to RTABLE, and the way you suggest that I did is rude. I suggested the opposite, in fact.

You still have not provided an example where the input is a scalar, eg. a sum who's terms are reordered. That's what you complained of at the beginning. So I'm giving up, since you steadfastly fail to provide that key example.

All you show now are examples in which the rtables are prettyprinted but the multiplication is inert. There are several supported and documented methods for doing that. Using an undocumented functionality for such is 4-alarm crazy.

@mmcdara It reads as if the OP expects his RTABLE calls to be treated in some particular manner by Maple stock interface and commands.

If he has assigned something to the global name RTABLE then he ought to show us. I expect he would have done so, were that the case.

Calls to RTABLE are used (internally) for printing and saving (of output to .mw) of rtables, when the relevant interface setting is typesetting=standard, etc. Assigning a procedure to name RTABLE which returned something unexpected would mess up that mechanism. The name should probably be included in the Help page UndocumentedNames , and protected.

@mapleatha You wrote, "You are trying to replace RTABLE by other instructions..."

That is false, and that is not what I showed. I showed an example of where RTABLE function calls get created and used (within the print-extension procedure `print/rtable`). I have made no attempt to replace calls to it by anything else.

You can look through that procedure I cited, and see how it constructs RTABLE calls. But mimicing even that doesn't sound like a good idea to me. The calls are constructed for the purpose of display (including saving output in .mw files).

How do you know that your example call RTABLE(1,x^2) was ever intended to be interpreted meaningfully?

You've stated that you are not planning on providing a short concrete example of a problematic circumstance that making such a construction avoids, which is a pity since it means there is no explicit example of what it was supposed to achieve. You made a brief allusion to its being a mechanism to avoid re-ordering of terms in sums (possibly during printing!?), however you give no example of such so it's not at all clear what you mean there.

If you provide an example of the problems its use was intended to avoid then we might offer supported alternatives -- though it seems you may not be interested in that.

Isn't  n^2+n+17  a good fit?