There are several possible variants on an approach using an inert operator for the special construction, a corresponding custom print-extension for it (to get the pretty-printing effect on output), and the simple value command as an easy mechanism to undo it.

For example,

Download unit_fun.mw

To a certain extent you can enlarge a Slider's length, and accompany that by forced larger dimensions for the exploration. Personally, I find that it's easier to utilize the Slider's (albeit, limited) precision if it is longer.

For example, with adjustment to borders only for understanding,

Explore( plot(a*x),
         width=700, tablealignment=left,
         tableborders=false, showhiddenborders=always,
         parameters=[ [a=1.0..2.0, width=500]] );

There's a limit to this, however, since there's some internal Explore code that automatically gives a portion of the overall width to the parameter/value labels on each side. Getting a much wider Slider might currently necessitate specifying the whole exploration to be wider than the GUI, or fiddling with Table properties manually, post-insertion. (That functionality might be improved in the future, perhaps by smarter weighting.)

But IIRC the limit of granularity of sampling of a Slider with a floating-point range is GUI side, and cannot be adjusted arbitrarily -- though minor tickmarks can give a little relief. The same goes for the numeric formatting of the labelling on the Slider itself.

The displayed value beside the Slider (in a separate Label) might also be improved, if Explore were to allow specified numeric formatting for such, within the parameters option. That might be quite useful.

ps. By manual adjustment I mean manually using the mouse to turn on all interior Table's borders, adjust Properties, and adjust Slider length property. This sounds unpleasant, since I don't know if all weighting aspects could be so altered adequately.

pps. Really fine granularity might be accomplished by scaling, eg. replace the instance of the parameter in the plotting expression by constant+newname, etc. You've probably already considerd that kludge. You could even "split" a parameter into a sum , each providing a carefully rounded value on two distinct scales (ie. 2-3 base 10 digits places, each).

Download cannot_plot_ac.mw

I'll file a bug report.

Your phi[1] and phi[2] might agree at x=0, but not for other mirrored x values. And their respective max and min might also not agree everywhere else, over the given ranges.

So when you pass just contours=25 then contourplot will automatically choose a different selection of 25 contour values for phi[1] than it does for phi[2]. And if the choice of contour values are not the same for both plots then there's no match-up along x=0, ie. the y-axis.

But if instead you specifiy the particular contour values -- the same for both phi[1] and phi[2] -- then the matching at x=0 can be made apparent.

By the way, in Maple 2023 there's no need for using that contplot procedure, since its only purpose is to allow a legend that mimics a color-bar. In Maple 2023 that color-bar is available (by default) from the actual plots:-contourplot command. I haven't changed that aspect.

Below I use Maple 2023, and in older versions you'd need to remove the colorbar option.

Download h-x_nemodar-e_ac.mw

Download PlotUnit_ac.mw

I've tried to adjust the methodology to get better performance from the numerical integration computations of eq7 & eq8 after the substitutions.

Getting that fast (for individual values of alpha and beta) is, naturally, key to figuring out efficiently from purely numerical computations where the inequality might hold.

I'm pretty sure that the following adjustments to calling evalf/Int, etc, gets a faster computation than merely removing the unapply, as CW suggested in his Answer.

More importantly, your original pointplot approach would compute something like 26*900 times, for alpha and beta sampled in a evenly spaced grid. A fine grid sampling is often an unnecessarily expensive way, and gets only a coarse visual of an inequality.

Let me know if this below is helpful. (You were originally sampling 10^(-9) to 1=10^0, etc. I've changed the ranges a bit.)

Download NestedError_accc.mw

ps. Your original approach was also flawed in how it generated the pointplot data pairs. The table M was converted to a list, but the i values (indices) were being dropped, that way. If the inequality didn't hold (or the integration failed) then there'd be no value stored in M. So not all i values are even implicit in the M data. The generation of the pointplot pairs was thus all muddled up, using the wrong i values for the stored j values in M.

Purely numeric integration can be quicker, here. (The later plot done in 22ms.)

Is this result as expected?

Gaussian_integration_ac.mw

Is this the kind of thing that you're trying to accomplish?

Download coeff_ex.mw

I'm not sure what collect has to do with this.

ps. The name eta also appears in the trigh/exp calls, eg. sinh(k*eta). Is it possible that you might want/need some kind of (truncated) series in eta?

Using active product instead of inert Product, the following can be done.

I think that it needs Maple 2018 or later, though, and not the Maple 2015 you used.

Download From2to7_ac.mw

Is this the kind of thing that you want to accomplish?

Download 2nrm.mw

ps. If you've loaded the LinearAlgebra package then you could simply call Norm(V,2) .

The plots:-display command can also handle a sequence of plots.

And the seq command can turn your Vector of plots into a sequence of plots.

Download JFKWEdgeDifractionDirection_ac.mw

You could also turn your Vector into a list and pass that instead, eg. you could do one of these:
    plots:-display([seq(lc)]);
or,
    plots:-display(convert(lc,list));

(While repeatedly appending to a Vector is not the most efficient way to construct your Vector of plots, I didn't change that aspect.)

ps. Your attached worksheet was last saved in Maple 2018, and not Maple 18 (released: year 2014).

Is this the kind of thing you're trying to accomplish?

Download subsc_diff_ex.mw

The unapply command is what you need here.

It has been available in every Maple version for decades.

Below, I use the unapply command to construct a re-usable operator (procedure) from the output expression than was assigned to fin.

Download unapply_ex.mw

Instead of trying to reset that numbering you should improve your program so that it is robust with respect to the naming of such introduced variables.

Let's suppose that you have an expression assigned to expr, which might be a solution from solve (or a list of set of such, etc). Then you can issue,

    indets(expr, suffixed(_Z,posint))

and get a set of such names present in the expression.

You can then programatically substitute for the introduced name(s) into the expression, without having to hard-code the name.

For example,

expr := solve(cos(x*Pi),x,allsolutions);

        expr := 1/2 + _Z5~

nms := indets(expr, suffixed(_Z,posint));

          nms := {_Z5~}

eval(expr, nms[1]=6);;

              13/2

seq(eval(expr, nms[1]=v), v=1..6);;

      3/2, 5/2, 7/2, 9/2, 11/2, 13/2

Notes:

1.) The need for robust handling of indeterminate names is standard stuff.

2.) Resetting that counter isn't a great idea in general. Different solutions with potentially differently assumed introduced-names should have such names be distinct, regardless of whether the assumptions happen to be. (I'm deliberately going to not mention how to do it.)

Based on your description so far, I'd suggest using a PlotComponent within your document, to get that aspect of interactivity.

If you read the Help page for that embedded component you'll see that the Component Properties (clickx, clicky) can provide you with access to the position of the mouse cursor when you Click (or Click&Drag) on a 2D plot frame. Similarly for the properties endx and endy, when a Drag ends, or hoverx and hovery when the pointer hovers over.

That access is also conveniently programmatic, and fits in well with triggering/working with other interactivity. The x- and y-values can be easily used for other computations, in a manner straightforwardly consistent with other interactive purposes (and documented for such).

The plot `annotation` mechanism is more convenient (IMO) for displaying the x- and y-values in a formatted "hover-over" frame over the plot (though it's possible it might be used programmatically to trigger an embedded component action elsewhere). It has more functionality related to closeness of plotted features in the plotting frame.

I'm not able to tell from your Question and details so far which is closer to your situation and wider goals.