This attachment has two ways to handle your followup example, which you gave as,

   fcty := RootOf(T, r);
   polarplot(fcty);

mpprime_acc.mw

[edit] I've replaced my earlier attachment and removed the method=_d01ajc suggested by Preben for your original issue, which works well in Maple 2020.2 but not Maple 2021.1 due to a bug. I have replaced that method specification by use of the operator-form calling sequence (using unapply), as an alternate mechanism for prevent discontinuity checks. This works quickly in both my Maple 2020.2 and 2021.1.

By the way, it looks like you're still using Maple 2020.0, and the update to point-release 2020.2 is a free download.

The animate command is part of the plots package.

It won't work if you call the only plain name animate without having loaded the plots package (or that command).

It works for me if instead I call it as plots:-animate, or plots[animate] in very old versions. Ie,
   F:=...
   plots:-animate(...)

It works for me if I first load that command from the plots package. Ie,
   with(plots,animate):
   F:=...
   animate(...);

It works for me if I first load the whole plots package. Ie,
   with(plots):
   F:=...
   animate(...);

It's not quite clear precisely how you wish to extend your given example.

But this might give you some hints, as two ways to regenerate your given example, along with a simple extension.

restart;
my_alph := [ "A1", "B1", "C1", "D1", "E1", "F1", "G1", "H1", "I1",
             "J1", "K1", "L1", "M1", "N1", "O1", "P1", "Q1", "R1",
             "S1", "T1", "U1", "V1", "W1", "X1", "Y1", "Z1", "AA1",
             "AB1", "AC1", "AD1", "AE1", "AF1", "AG1", "AH1", "AI1",
             "AJ1", "AK1", "AL1", "AM1", "AN1", "AO1", "AP1", "AQ1",
             "AR1", "AS1", "AT1", "AU1", "AV1", "AW1", "AX1", "AY1",
             "AZ1", "BA1", "BB1", "BC1", "BD1", "BE1", "BF1", "BG1",
             "BH1", "BI1", "BJ1", "BK1", "BL1", "BM1", "BN1", "BO1",
             "BP1", "BQ1", "BR1", "BS1", "BT1", "BU1", "BV1", "BW1",
             "BX1", "BY1", "BZ1" ]:

AZ := StringTools:-Explode(StringTools:-Iota("A" .. "Z")):

ans1 := [map(cat,AZ,"1")[],
         map[2](cat,"A",AZ,"1")[],
         map[2](cat,"B",AZ,"1")[]]:

evalb(ans1=my_alph); # they are the same

               true

ans2 := [seq(map[2](cat,p,AZ,"1")[], p=["","A","B"])]:

evalb(ans2=my_alph); # they are the same

               true

#
# And now one way to extend it. (output omitted...)
#
[seq(map[2](cat,p,AZ,"1")[], p=["",AZ[1..7][]])];

Do you need to know how to get a generated list whose desired number of entries is known beforehand, but might not be a multiple of 26? The math for that is not difficult, but I don't know whether you need that step. Would you want that number constructed from the ranges of values that Ql, Tl will take?

The last example above can be modified, say altering the p=["",AZ[1..7][]] portion to get additional entries or nesting.

In 2D Input mode, use the key-strokes y _ _0 ( ie. y underscore underscore 0 ) to enter a subscripted name for the initial value. (That keeps the variable distinct from the name y.)

In several places your document muddles up text, inlined 2D Math, and executable 2D Input.

Also, your sheet does quite a lot of cut&paste of values, but you could instead make it flow nicely in a programmatic manner. Ideally you should rarely if ever have to cut&paste previously computed values, since that is error prone, awkward to read, and does not allow recomputation if any parameter values are changed, etc.

See attachment, and check for mistakes(!).

Worksheet_1_ac.mw

Adjust to suit your own style, add back the removed commentary, etc.

Note that some of your original comments are incorrect. For example you had, "Now that we know that the half-life of the isotope is roughly 0.693147180559945 years..." but that is wrong. The half-life is given as 24360 years. The computed value 0.6931.. simply approximates ln(2). What you were solving at that part of the sheet is actually the value of the parameter k.

Member vv is correct, in that the Tabulate approach in Maple 2015 needs interface(typesetting=extended) or equivalent for the piecewise call to pretty-print as desired. In Maple 2017 the default was changed to extended.

Also, in your DocumentTools:-Layout approach the calls to Equation could simply be passed the (documented) typesetting=extended option. So both approaches can work even in Maple 2015.

See attached,

DT_piecewise_ac.mw

Your followup remark used the word "depends". And since that is what seems to really matter here, why not utilize the depends command?

Also, it seems more robust to remove the piecewises which depend upon x, rather that merely select those which happen to have identically t as one side of only some non-compound relation.

I added conditional t<0 or x[1]<0 to make it harder.

expr := piecewise(x[1](t)<0, -1, x[2](t)<1, 0, 1) + f(t)
        + piecewise(t<0, 0, t<1, 1, 0) + x(t)*piecewise(t<0, 1, t<1, 0, 1)
        + a*piecewise(t<0, 3, t<1, -1, 2)
        + a*piecewise(t<0 or x[1]<0, 3, t<1, -1, 2);

# testing whether the piecewises depend upon x
#
indets(expr,And(piecewise,
                satisfies(pw->not depends(pw,[x]))));

# testing only whether the conditionals of the piecewises depend upon x
#
indets(expr,And(piecewise,
                satisfies(pw->not ormap(depends, op~(1,PiecewiseTools:-ToList(pw)),[x]))));

# first of those, but in two separate steps...
indets(expr, piecewise);
remove(pw->depends(pw,[x]), %);

pw_depends.mw

This is not fast, since it has to decode the 2D Math contents.

But it can help in the case that the input code is in only 2D Math form. Ie, when the desired/queried-for code appears only in 2D Input but not also as plaintext.

This approach also happens to search the 1D Maple notation plaintext code, as well as conversions of input from 2D Math.

rough_mw_text_search.mw

Of course you'd need to adjust how ListDirectory is called, for your machine and directory locations. You could also make it more defensive, add bells & whistles, etc.

By the way, the Maple program code contents are not in a "binary format". The encoded portions are in a base64 encoding of Maple's .m dotm format. That is neither impossible to decode nor exceptionally strange, and in the attachment that aspect is all handled automatically by the WorksheetToMapleText command.

ps. On my Linux machine I use its grep utility to search files for plaintext strings. But 2D Math is a trickier situation.

The "Dragged" action code of a PlotComponent is called multiple times while the mouse-pointer is dragged around. (The frequency at which it gets called is not adequately documented.) But that is the main difference between the "Dragged" code and the "Drag end" code which is only executed once per drag, when dragging stops. The "Dragged" code allows you to get a kind of continuous effect, programmatically, as the mouse is dragged around the plot.

Here is a simple example, with comments.

ECPlot_dragged_example.mw

I prefer to make the relevant "action code" property of the Component be just a simple call to a procedure that I define elsewhere. That makes it easier to adjust the code. Eventually such code could be tidily hidden away inside, say, the Startup Code Region of the worksheet.

It's easy to make other fun applications. This second example uses the endx,endy pair as initial value for a phase-portrait of a 2D ode solution, using DEplot. As you drag the mouse-pointer around the resulting solution curve moves through the field-plot. Execute all the code in this attachment, then left-click&drag around the plot...
ECPlot_dragged_DEplot_example.mw
(This example is designed for simplicity, not efficiency. Otherwise I'd call dsolve once up front, and then odeplot in the action code.)

The .mws file from the Application Center loads in Maple 2017.3 with the definitions of id, eq1, and eq2 missing.

I retyped the three missing definitions, by reading the display rendered on the App Center. (Check for mistakes in my transcription.)

I also corrected the faulty calls to plots:-odeplot. (Even the display on the App Center page demonstrates those as being wrong.)

Download half-wave_full-wave_diode_rectifiers_ac_2017.mw

I will submit a bug report against that App Center item.

plots:-textplot({[4.2,1.9,sin(nprintf(`#mn("%a°");`,30))]},
                symbol=point,color=black,
                font=["Arial","Bold",25]);

Naturally, you could also define a reusable procedure for constructing those. Eg,

F:=v->nprintf(`#mn("%a°");`,v):

plots:-textplot({[4.2,1.9,sin(F(30))], [4.2,1.2,sin(F(35.6))]},
                symbol=point,color=black,
                font=["Arial","Bold",25], view=[2..6,0..3]);

seq(F(15*i), i=0..6);

etc.

All the above worked in my Maple 16.02. I suspect it would work in Maple 13. Let us know.

Carl has already explained that your original mistake is using coords=spherical when it was not appropriate to your formulation.

I'd like to make some additional comments, and show one more variant.

In some examples below I will use a slightly different method to generate the lower cap (base disk), simply because some approaches work better according to how the spherical surface is generated. The result is better if there are no visible chinks and holes where light shows through the intersection between the base and hemisphere (upon manual rotation, say).

I often use 3D plots with style=surface (a.k.a. patchnogrid), with the default lighting. But I really dislike any shadow artefacts, which can occur where the surface's parametrization's end-points occur. I'll show what I mean below. The emphasis here is on the visible rendering quality of the spherical portion.

Take this approach similar to what Carl suggested.

H1:=plots:-display(
     plot3d(3,th=0..2*Pi,phi=0..Pi/2,coords=spherical),
     plot3d([r,theta,0],r=0..3,theta=-Pi..Pi,coords=cylindrical) ):
plots:-display(H1, scaling=constrained, orientation=[180,77,170], style=surface);

You can see the vertical seam's shadow, along the surface. That happens whether one uses the parametric calling sequence (as Carl did) or the scalar calling sequence (as I've done here). Increasing the grid resolution doesn't fix this. This is a drawback to this approach.

Now consider this quite natural approach using cartesian coordinates (which the OP has alluded to in a subsequent posting).

HR:=plots:-display(
     plot3d(sqrt(9-y^2-x^2),x=-sqrt(9-y^2)..sqrt(9-y^2),y=-3..3,style=surface),
     plottools:-transform((x,y)->[x,y,0])(plottools:-disk([0,0],3)) ):
plots:-display(HR, scaling=constrained, orientation=[90,77,170], style=surface);

Near the points x=0 and y=+-3 there is a nub on the spherical surface, around which there is a circular shadow artefact. Increasing the grid resolution in both directions reduces this, but making it negligible raises the memory cost and GUI rendering burden considerably. This is a drawback to this approach.

So here is another suggestion: using a rotation of a spherical coordinates plot over a different range, created so that the "parametric seam" lies horizontally along the edge of the spherical surface -- essentially becoming hidden.

H2:=plots:-display(
     plottools:-transform((x,y,z)->[x,z,y])(plot3d(3,th=0..Pi,phi=0..Pi,
                                                   coords=spherical)),
     plottools:-transform((x,y)->[x,y,0])(plottools:-disk([0,0],3)) ):
plots:-display(H2, scaling=constrained, orientation=[180,77,170], style=surface);

You can manually rotate that 3D plot and notice that neither of the previous two kinds of shadow artefact are visible. I think this is a better solution, for the case where style=surface is used.

I'll move on to a couple of relatively minor points.

Carl showed how you can put a circular cap below the hemisphere, to make it appear as a solid, and I have no complaint about how he did it. I'll mention that there is memory savings possible since the radial grid-resolution of the cap only needs to be 2 rather than the default 49, if the surface grid-lines don't matter or aren't wanted. (The disk's circular grid-lines don't match those projected from the spherical portion, even in the original.) The following is almost half the size in memory, and for rendering multiple 3D plots that difference can really affect GUI performance.

plots:-display(
  plot3d(3,theta=-Pi..Pi,phi= 0..Pi/2,coords=spherical),
  plot3d([r,theta,0],r=0..3,theta=-Pi..Pi,coords=cylindrical,grid=[2,49]),
  scaling=constrained);

Also, If the original is shown magnified then some non-smooth points along the outer circular edge are discernable, especially when the grid-lines are shown. So, optionally, one could re-use some of that saved memory space and also increase the theta grid-resolution. Eg. the following produces a smoother, rounder edge and surface:

plots:-display(
  plot3d(3,theta=-Pi..Pi,phi=0..Pi/2,coords=spherical,grid=[106,70]),
  plot3d([r,theta,0],r=0..3,theta=-Pi..Pi,coords=cylindrical,grid=[2,106]),
  scaling=constrained);

I think that last is a decent solution for the case where the wire-frame grid-lines are wanted (including the default style).

Lastly, I'll mention that I really don't like what plottools:-hemisphere produces for both spherical portion or base disk: a visually inferior collection of polygons with visible edges, and much less flexible coloring functionality. It's awkward and memory intensive (and burdensome on the GUI) to get something even approaching a very smooth surface with this approach.

Your first example (Q1) might be handled as follows, using the Logic:-Complement command which was introduced in Maple 2016.

restart;
with(Logic):
local O:

P1 := (&not O) &and (&not C) &implies (&not Q);

Complement(&not(P1));

See also,

Complement(&not( A &implies B ));

Lc_ac.mw

Of course, you can combine this pair of commands into a single statement, without utilizing a temp assignment, eg,

   subsop(ListTools:-Search(1, L)=NULL, L)

If the specified element is not present in the list then that would throw an error, naturally, about use of an improper op or selector.

Download ListSearch.mw

In a .mw file Worksheet/Document you can make an imported Matrix be the data (rtable) associated with a DataTable Embedded Component.

You don't need to utilize any special commands to further access that Matrix data -- simply use the name to which the Matrix is assigned, in usual ways.

A Matrix associated with a DataTable by name is stored in the Worksheet .mw file, and automatically accesible following restart or Close/Reopen.

You can even toggle off the visibility of the DataTable, effectively hiding it from overt view.

The above is one way you might accomplish the question as asked -- to actually store the data in the Worksheet so that it is accessible upon re-opening without need for re-import.

If you merely want to automate and hide the step of importing from the data file (.csv file, etc) then you could place the importing command inside the Startup Code region of the Worksheet/Document.

Did you try using the full path to the file? Eg,

   "C:\\\\Users\\Sriram\\Downloads\\temp_file.txt"

or,

   "C://Users/Sriram/Downloads/temp_file.txt"

Note that backslashes are escaped with an extra backslash (each). Most relevant commands in modern Maple also accept single (unescaped) forward slashes.