@student_1 Yes, I did in fact understand what you meant before. You can get that "legend" effect for the pointline style (as well as the particular placement), through a construction of the whole legend-thing via segments and textplots.

@student_1 Using various other symbols is easy and straightforward. See the symbols option in the plot,options Help page. Simply replace the symbol=solidcircle in the above code with your choices from the documented symbols.

Maple's legend and caption options don't support the location your last Reply's image shows. The inlined location of that "legend" in your image is possible if you programmatically build it up through use of carefully placed smaller plot segments and textplots. But those all have to be placed with some care/fiddling -- its construction and placement is not automatic.

[edit] Just to be clear: when constructing the short line segments in such a construction the style=pointline could be used, or two segments with style=line and style=point could be overlaid. It's not difficult, but it is extra effort to set up.

If you have in mind such a specific kind of plot then it would have been more helpful and useful to have shown it when you first asked the original Question.

@snowman If you have an older version of Maple then you can specify that at in the header of your Question. That often saves time, avoiding back-and-forth fiddling.

I'd like to clarify that at no point have I suggested that dismantle produces the desired tree described by the OP. Some comments above seem to have confused that, and muddied distinctions between internal DAG structure and functional form.

I mentioned dismantle only because it uses a vertical rather than horizontal layout. I think that vertical layout can be a useful alternative.

The OP has now clarified the class of examples to be covered. Even for a meaningfully wider class the computations can be done easily with the op command (perhaps using lists as intermediate representation). This sort of thing has been done several times before. Using ToInert for the given task involves considerable unnecessary additional effort.

I don't recall anyone suggesting before that this functionality be made into a new command. That's a nice idea.

@mmcdara I didn't write that documentation phrase, so I cannot state what its author meant precisely.

I could suggest that the main difference is that ToInert produces something which can be programmatically manipulated, as opposed to dismantle which is more for a purely printing/display effect.

But I don't know what kinds of expression you wish to cover, and how. Certainly there is more work to be done in order to manipulate structures returned by ToInert. In many cases using op directly on the original expression seems simpler and easier. (Recall my response in another recent thread of yours, using both op(0,...) and [op(...)] .) But that won't serve for everything... It depends on what kinds of expression and structure are to be covered.

@nm That looks like showing the result of applying FullSimplify to the result from Rubi, rather than showing the result from Rubi. Are they the same?

Such graphs can become unmanageable when they get too wide, as nesting deepens.

You might consider a vertical orientation, on grounds of practical visibility.

On that note, and in a similar vein for displaying the nested structure of an expression, there is the dismantle command. (Much of it now implemented in a Library module, which can be viewed as source.) That is just a plaintext way of presenting the tree.

dismantle( (x+1)/(x-1)^2+sqrt((exp(-x^2)-1)/(x+1)) );                                

SUM(5)
   PROD(5)
      SUM(5)
         NAME(4): x
         INTPOS(2): 1
         INTPOS(2): 1
         INTPOS(2): 1
      INTPOS(2): 1
      SUM(5)
         NAME(4): x
         INTPOS(2): 1
         INTNEG(2): -1
         INTPOS(2): 1
      INTNEG(2): -2
   INTPOS(2): 1
   PROD(3)
      PROD(5)
         SUM(5)
            FUNCTION(3)
               NAME(4): exp #[protected, _syslib]
               EXPSEQ(2)
                  SUM(3)
                     PROD(3)
                        NAME(4): x
                        INTPOS(2): 2
                     INTNEG(2): -1
            INTPOS(2): 1
            INTNEG(2): -1
            INTPOS(2): 1
         INTPOS(2): 1
         SUM(5)
            NAME(4): x
            INTPOS(2): 1
            INTPOS(2): 1
            INTPOS(2): 1
         INTNEG(2): -1
      RATIONAL(3): 1/2
         INTPOS(2): 1
         INTPOS(2): 2
   INTPOS(2): 1

@J F Ogilvie Yes, the call to `simplify` prevents the crash (for those posint values of j).

I put in the `unapply` to gain speed, by preventing potentially expensive discontinuity checks on the integrand.

I had edited my response above, to indicate that I'd submit a bug report. The crash is due in part to the handling of the special functions, I believe. It is a regression bug.

@vv If the source is copied to text file then applying the `mint` utility may be as useful as using the `read` command. It covers more syntax issues in general.

The `mint` facility is part of what Startup Code regions utilize as syntax checkker, but with less flexibility as to controllong mint's options.

If the code in the worksheet is edited to be a string then that can be sent programmatically to external mint (similar to what's done in an old Post of mine).

I don't bother with the weaker `maplemint` command, even when it can be used.

@AHSAN From your comments so far I don't see that you really need these explicit symbolic representations of the roots. I don't see why you cannot solve numerically, later on when a and b take numeric values. It's also possible that numeric rootfinding might incur less numeric roundoff error than evaluation of the large explicit symbolic roots -- for given numeric a and b.

But recollections of having the same general conversation make me think that I should give up now on my arguments.

@nm Is there a box from which more examples will come later, or could you characterize the class of examples up front?

evala(Normal(expr));

                  2 /   (3/2)                 \
                 y  \3 y      x + sin(x) y + 1/

frontend(factor, [expr, y^(1/2)], [{`+`,`*`},{y^(1/2)}]);

                  2 /   (3/2)                 \
                 y  \3 y      x + sin(x) y + 1/

Could you also explain explicitly why that is better than, say,

evala(Factor(expr));

                  (7/2) /     sin(x)       1    \
               3 y      |x + -------- + --------|
                        |       (1/2)      (3/2)|
                        \    3 y        3 y     /

@AHSAN Yes, the unsimplified roots are very large symbolic expressions.

You can simplify them, which in this case reduces their size considerably.  help.ac1_ac.mw

What do you plan on doing with these symbolic roots? If you intend on (eventually) doing further computations that involve numerical evaluation at values of the parameters (a,b,c) then you might be better off waiting until that time and then doing numeric root-finding instead.

@J F Ogilvie I did not state that there was no crash, with the integrand left unsimplified following instantiation at those positive integer values for j.

I pointed out that, following instantiation at those positive integer values for j, the integrand simplifies into an expression containing only elementary functions (exp, and arithmetic operations). That is related to why the numeric integration succeeded in the code in my Answer.

@mmcdara  No worries. One could also add,

op(0,I), [op(I)];

              Complex, [1]

op(0, 2.1), [op(2.1)];

             Float, [21, -1]

@J F Ogilvie In case you had not noticed, for each of the concrete integer values of j=1..5 that call to simplify turns the integrand into an expression with only elementary functions (ie. exp but not GAMMA or LaguerreL).

I have not tracked down what all the causes of crashing are here, when the integrand is not simplified and still contains the special functions.

[edit] I now know what is the direct cause, and will submit a bug report.