@mmcdara Yes, the double underscore is just to avoid collision with other names (including special ones).

Another way to do such things is to use an anonymous procedure which is called directly. In such a way name collision is avoided, as the temporary names are local. For example, the following is procedure call of an anonymous procedure. Note the round brackets at the end.

   proc() local LL,KK,KO,NN,ver; ....etc... end proc():

@opus64 Right, that is why I stated that, "the optimal solution would be for each parameter's label in each separate exploration to be able to retain its own independent formatting specification."

By the above I meant a scenario in which each parameter could get its own individual treatment, and in which that individual treatment would be part of the embedded exploration's (handling of the) individual Slider components (and not the package's general common runtime).

At present there is no way to get distinct formatting for distinct parameters (eg, with values on quite different scales).

@mmcdara Thank you. However, your claim is not true, in several ways.

For regular output, the following can be done (since about Maple 18 or whenever 2D plots got the size option):

Resize:=proc(P,m::posint,n::posint)
      op(0,P)(op(P),ROOT(BOUNDS_X(0),BOUNDS_Y(0),
                   BOUNDS_WIDTH(n),BOUNDS_HEIGHT(m)));
   end proc:

P:=plot3d(cos(x)*y^3,x=-Pi..Pi,y=-1..1):

Resize(P,700,700);

The difference is that the code in the Post (at top) enables the size option to be used directly in each plotting command. That's more direct than modifying a generated 3D plot result, after generation, with such a Resize procedure. That is the central idea of this current post.

Since you mention DocumentTools, well, there too it is possible to embed a plot that is either smaller or larger than default. Your code snippet is just not one of the ways to enlarge it. The DocumentTools facilities also allow for embedding of programmatically scaled and panned plots. But note that these DocumentTools mechanisms are only for embedded display effects, whereas the size option produces a plot as output/return-value and which carries its size details as part of its structure. 

Upload a .mw Document/Worksheet that reproduces your problem in full.

You can make it at attachment here  using the green up-arrow in the mapleprimes editor.

@mmcdara In this attachment (made with Maple 2015), it does what you've shown except for showing one step separately.

That omitted single step is the bringing of the inert Diff inside the inert Sum, prior to actually differentiating. It could be done, but perhaps not in a way that makes the mechanism natural for any non-Maple-user audience.

The loading of student is to get the Sum expansion in Maple 2015. The extended typesetting mode is to allow inert `%.` to prettyprint nicely, since not default in Maple 2015.

Download SimplifySum_bis_ac.mw

@vv Thank you very much for the comments.

I believe that the failure to auto-scale (to a square the size of the smaller dimension) for the case you mention is fixable. I have also observed somewhat new behavior when manually resizing purely horizontally, on occasion, and I've reported that regression recently. But the case of a purely square window, or oblong in the other orientation, seems fine..

I also believe that the case you describe is quite uncommon, since if behaving fixed it would incur the wasteful white space above and below (which is unpopular). Or one could simply force a large square. So, either undesirable or already attainable.

I would also like new plot substructures to denote the axis ratios, and the pan and zoom. The latter pair of those are currently stored in the XML of a .mw file but not in the actual plot structure; ie. Maple language. So some of those effects can be achieved by embedding with DocumentTools, but not with regular output. There is an example of an animation within a long prism in the Help, where the 3D plot shows without the usual unfortunate large white spaces above and below.

Small steps...

I have posted a patch/edit attempt here:
    https://mapleprimes.com/posts/211817-3D-Plot-Size-Option

@Thomas Richard A minor comment: data could also be split with,
   xdata := data[..,1]: ydata := data[..,2]:
 

@amrramadaneg Why haven't you answered Carl's questions?

As stated your question doesn't make sense.

@arashghgood What are the values of alpha and beta, exactly?

Your explanation is inadequate.

Do you have the context-panel open on the right? Is the behavior the same if you close it?

@Kitonum This code relies on ListTools:-Collect for its crucial task of tallying the data, a command which was introduced only in Maple 2017.

In contrast, the Statistics:-Tally command predates that by many years, and its output can be quite easily used to form the coordinate pairs obtained from ListTools:-Collect even if more general plotting is wanted.

In Maple 2016 these get me a similar effect:

with(Statistics):
L := [1,2,2,2,3,3,4,4,5,5,6,6]:

Statistics:-Histogram( L, binwidth=1-1e-9,
                       view=[min(L)-1..max(L)+1,0..0.3],
                       xtickmarks=[{L[]}[]] );

Statistics:-Histogram( L, binbounds=[seq(min(L)-0.5..max(L)+0.5)],
                       view=[min(L)-1..max(L)+1,0..0.3],
                       xtickmarks=[{L[]}[]] );

T := table(Tally(L,output=list),sparse):
S := {L[]}:
LL := [seq(i=T[i]/nops(L),i=min(S)..max(S))]:
ColumnGraph(LL, datasetlabels=none,
            offset=0.5, distance=0.0, width=1.0,
            view=[min(L)-1..max(L)+1,0..0.3],
            xtickmarks=[seq(i,i=min(S)..max(S))]);

hist_2016.mw

@Adam Ledger No, you most certainly did not mention that the argument in the call to ListDirectory (ie, the currentdir() value) was supposed to be the same folder as you were trying to access on the H drive. Go back and read your own Question. You didn't explicitly assert that, and (in part because ImageTools:-Read expects a file name) it is a stretch to claim that it was implied. Perhaps you could reflect on the fact that your questions are often unclearly phrased.

The ImageTools:-Read command expects the name of an image file (or a URL that points at such). But now you seem to be suggesting that you are passing it the name of a folder. And you are not using any filename extension in the string. Don't you see how this confusion makes the precise name of the image file a central concern here?

You still have not told us the fully qualified name of the image file you want to read. You claim that it is "not really relevant". I suggest that it could be intrinsically useful in figuring out the causes of your problem -- even if one cause is something other than the file's name.

Why would you post such a question without precisely stating the full location and name of the image file which you are trying to read?

How does that call to ListDirectory have anything to do with your call to Read?

Why are you starting off the string with an escaped backslash?