@mvms271091 You may use an empty string "" for the second legend item, which will get suppressed. For example,

f := (3*t)/(1 + t^3):
g := (3*t^2)/(1 + t^3):
plot([[f,g,t=-40..-1.5],[f,g,t=-0.6..40]],
     style=point,symbol=cross,symbolsize=12,
     colour=coral,legend=[foo,""]);

You could do the same thing using, say,
  `[]`~(f,g,t=~[-40..-1.5,-0.6..40])
instead of,
  [[f,g,t=-40..-1.5],[f,g,t=-0.6..40]]

@Ivi Please don't post duplicate Question threads for this, though it might not yet be answered here to your satisfaction.

Here is an example of doing it with a procedure.

The scaling=constrained is needed so that the icon doesn't get distorted. An alternative that would estimate the plot assembly's final size (aspect ratio) -- and use that to adjust the icon -- could become tricky in general.

Download image_plot2.mw

Yet another alternative is to build a background image for the whole plot-window, with instances of the icon as carefully placed subimages. Then the aspect-ratio of the icon images could be handled based on any forced size option choice. This approach wouldn't allow the icons to be laid over a densityplot example, however.

@mmcdara In terms of (kernel, at least) efficiency an improvement would be a procedure.

It could accept, say an x,y pair as center point and width/length (or two opposite corner x,y positions). It could then construct that PLOT(GRID(...)..) structure directly. The only thing needing computation would be the two ranges that are the first two arguments of the GRID(...) substructure.

That would be more efficient than `plottools` commands `transform` or `translate`. It would also allow the two float[8] rtables to remain as such, which might even be kinder to the GUI.

@mvms271091 In my Answer I already gave,

DocumentTools:-Tabulate(widthmode = percentage, width = 75,
                                          [[seq([seq(p[3*(i - 1) + j], j = 1 .. 3)], i = 1 .. iquo(11, 3))],
                                           [seq(p[3*iquo(11, 3) + i], i = 1 .. irem(11, 3))]]):

where that latter part,
    [seq(p[3*iquo(11, 3) + i], i = 1 .. irem(11, 3))]
provides the 10th and 11th plots in a fourth row. It's harder to get that last row center-aligned without resorting to the building-blocks in which Tabulate is written (which is done in one manner in my Answer's second example).

Yes, your fresh attempt using,
   [seq([seq(p[i], i = (j-1)*iquo(11,3) + 1..j*iquo(11,3))], j = 1..iquo(11,3)+1)]
does not work because for the fourth row it refereces member p[12] which is not a plot. That is the whole point of the code fragment in my previous paragraph here.

Another terse way is something like,

DocumentTools:-Tabulate(widthmode = percentage, width = 75,
                        [[seq([seq(p[3*(i - 1) + j], j = 1 .. 3)], i = 1 .. 3)],
                         [p[10], "", p[11]]]):

where the middle cell now appears empty.

An alternative to the above is, say,

plots:-display(Array([seq([seq(p[3*(i-1)+j],j=1..3)],i=1..3),
                      [p[10], plot(axes = none), p[11]]]));

where the empty cell gets an empty plot.

Getting the last (fourth) row to be spaced exactly as you showed is trickier. That is why I also showed as a second example like this:

with(DocumentTools): with(DocumentTools:-Layout): with(DocumentTools:-Components):

InsertContent(Worksheet(Table(widthmode=pixels,width=600,alignment=center,interior=none,
                              seq(Row(seq(Cell(InlinePlot(p[3*(i-1)+j])),j=1..3)),i=1..iquo(11,3)),
                              Row(Cell(Table(exterior=none,interior= none,alignment=center,
                                             widthmode=pixels,width=400,
                                             Row(seq(Cell(InlinePlot(p[3*iquo(11, 3) + i]),padding = 0),
                                                     i=1..irem(11,3)))),padding=0,columnspan=3))))):

[edit] The general idea above is to use iquo and irem to construct first the 3 rows or 3, and then a row of the remaining items. Those are common techniques for splitting N objects into groups. Here's another way. If you are ok with using plots:-display, and don't need the botton row to have (center-aligned) fewer cells, then for a list p of N=11 plots you could also get it rendered in 3 columns as follows: question5_acc.mw

plots:-display(Matrix(ceil(11/3), 3,
                      (i, j) -> `if`(3*(i-1) + j > 11,
                                     plot(axes = none),
                                     p[3*(i - 1) + j])));

@Scot Gould I suspect that you're talking about a problem that affects all array-plots done using plots:-display, and not about the current query about how to deal with an odd number of plots.

There is a long-standing quirk in the GUI, such that when plots:-display is used for array-plotting the plots are all rendered left-aligned in their respective Table cells. There are two manual ways to correct for that: 1) using the mouse-pointer, select an outer (say, right) exterior border of the Table and adjust its position slightly, and 2) right-click in the Table and adjust its width property slightly. Those both cause the plots to properly realign at the Cell's centers.

This is one of several reasons why I prefer DocumentTools:-Tabulate over plots:-display, for handling Arrays/lists/Matrices/Vectors of plots, ie. the former doesn't suffer from this bug. And customized solutions using DocumentTools primitives even offers programmatic control of several choices of alignment.

I reported this problem (with intial Table rendering after calling plots:-display) years ago.

@Scot Gould Thank you. It was a typo in the accompanying text (now corrected). The code was already correct.

At the default settings (Digits=10<=15 and UsehardwareFloats=deduced) the Eigenvalues command will use parallelism within LAPACK.

The timings you describe hint that you are using a higher working precision, with software (rather than hardware double precision floats). We cannot tell because you haven't bothered to provide the code of your computation.

If the two attachments are the dotm (.m) format of your Matrices then you should inform us of that.

If this is a continuation of your very recent Question then you should provide the code you're using. You should provide the code anyway. It's OK if that means using read on .m files. But you really ought to provide the calls you make to do the computation as well as the Digits, etc.

There seems to be a problem with getting to the particular LAPACK function that benefits most from symmetric positive-definite A and symmetric B for the generalized eigen-problem. Instead it is calling the general (nonsymmetric routine) which is slower. But that is secondary to the slowdown you'll see moving from hardware Digits<=15 to higher precision software floats. But if you really need the higher precision then this might well be important. (I have not looked at the conditioning...yet.)

It's difficult to say more without your providing adequate details.

The fact that you appear to have unnecessarily split this into a separate Question thread is not very helpful.

note: The "generic" CLAPACK external code for higher (software float) precision is not parallelized. So it's slower for two reasons: 1) it's using software Maple-floats, and 2) it's not got the the same LAPACK parallelism as the hardware double-precision Intel MKL implementation. I don't know whether it is possible to beat the software float, generic, unparallelized eigenvector QRQZ compiled code with a Maple Threads/Grid parallelized implementation that does, say, separate nullspace (eigenspace basis) computations in parallel after finding the eigenvalues.

@mmcdara You may also declare names local at the top-level.

Then it becomes as straightforward to encapsulate such code within procedures. (Note that :- colon-minus syntax allows the original global name to still be referenced, if needed.)

IMO being able to declare the names (including a collection of nonpredetermined number) as local within a procedure is important. So often it becomes desirable to turn one-off code into reusable procedure(s). I reserve using double-underscore for base names that I'll never want to use to create several names (especially if the number may vary).

@mmcdara It's a personal preference, but I'd prefer to concatenate as little as possible. (The aliasing below re-uses the assigned displacements.)

Also, in general there might be other aliases in play, so you could target the ones you want here more precisely, again re-using displacements in the lookup.

Download purpose_ac.mw

Alternatively, if you create your new list (ie, your `a`) prior to making the aliases then you don't have to resort to concoctions to form it afterwards. Eg,

Download purpose_acc.mw

ps. You've been showing quite a bit of code using concatenations over the past year. But that doesn't allow safe local declaration within procedures, and so hinders programmatic encapsulation via procedures. Why do you use concatenated names instead of indexed names? (Both pretty-print with subscripts...) For example,

Download purpose_accc.mw

@sand15 The addresses of the names returned by alias() are not the same as the addresses of the original global names. That is why your attempt did not work. (This relates to the magic way that the kernel builtin procedure alias:-BuiltinAlias works.)

An alternative might be,

restart;

alias(f=f(t)):
alias(g=g(t)):

a:=[indices(alias:-ContentToGlobal,':-nolist')];

            a := [f, g]

diff(a,t);

            d     d
           [-- f, -- g]
            dt    dt

I will file a report.

It returned both (as lists) in my Maple 16.02, but not in 17.02.

@John2020 

Download taylor_frontended.mw

And, as alternate, using frontend rather than explicitly freezing,

restart;
with(Physics):

r := x*(diff(theta(t), t))^2+y*(diff(varphi(t), t))^2:
g := (4*(f+T))*(diff(theta(t), t))^2+u*(diff(varphi(t), t))^2:

frontend(solve,[identity(r=g,diff(theta(t),t)),[x,y]],
         [{`+`,`*`,`=`,list,specfunc({identity})},{}]);

           [[x = 4 T + 4 f, y = u]]

@John2020 If you load the Physics package then the name diff is rebound.

I wasn't suggesting that you instead try to freeze calls to Physics:-diff. I was trying to suggest that you'd need to distinguish between Physics:-diff and the original, global name (and try to ensure that it is the latter which gets frozen). I posted my earlier reply from a phone, which is why it is terse. Sorry.

The code I originally provided freezes calls to the name diff, without forcibly referring to the original global name :-diff rather than the current binding of that name. But it will continue to work -- even with Physics loaded -- provided that you refer explicitly to that global name :-diff instead of the rebound diff.

restart;

with(Physics):

r := x*(diff(theta(t), t))^2+y*(diff(varphi(t), t))^2:
g := (4*(f+T))*(diff(theta(t), t))^2+u*(diff(varphi(t), t))^2:

solve(identity(subsindets(r=g,specfunc(:-diff),freeze),
               freeze(:-diff(theta(t),t))),
      [x,y]);

             [[x = 4 T + 4 f, y = u]]