That Example unfortunately shows only how to have text use the current Style that is set for Hyperlinks, rather than an actual hyperlink.

There is a Hyperlink constructor exported from DocumentTools:-Layout, but it is not documented. It's also not a package export, so its name is not rebound by with. But it can still be called by its full name.

with(DocumentTools):
with(DocumentTools:-Layout):
F := Font("Official NORAD Santa Tracker", size=12, color=blue, style=:-Hyperlink):
H := DocumentTools:-Layout:-Hyperlink(F,linktarget="https://www.noradsanta.org/"):
InsertContent(Worksheet(Group(Input(Textfield("Track Santa at the ",H))))):

It is not a bug. But it is a commonly asked question.

for i from 1 to n do a[i] := unapply( b[i](u), u); od;

I consider it safe to assume that you've given us a toy example merely for the purpose of illustration, and that your actual examples are more involved. Otherwise you could assign more directly from b to a, or b[i] to a[i]. I assume that you are not working with this trivial task.

If you have a more involved example for which the above approach does not work as you want then show us the full example. There are too many variants to guess thoroughly.

Eg, you might want the i in  b[i] to be resolved in the body of the new operator/procedure -- while neither b[i] nor the call b[i](u) are yet resolved explicitly or executed. That could be done as follows, which also handles even more complicated cases,

for i from 1 to 2 do
   a[i] := subs(__dummy=b[i],(u->__dummy(u)));
end do;

Such subtleties might not matter to your workflow. It could conveniently allow you to change any or all of the definitions of the b[i] without having to reassign the a[i]. That might well not matter to you.
 

Substitute for 1-gamma first, using e_nsp2. Then you can substitute for gamma using e_nsp1 (without interfering with the original 1-gamma terms).

(You could also separately freeze the relevant terms 1-gamma and gamma, and then do the substitutions together. But your example seems unambiguous and so this may not be necessary here.)

Download question_1_ac.mw

You are missing a comma between the 3rd and 4th equation in the definition of Inter.

Also, did you realize that Inter contains lambda[1], etc, while the eqs and Sol contain lambda__1, etc? I'm not sure which you want, but I've changed them to match, here. tes_ac.mw

I suspect that the real lesson to learn here is: Do not evalf non-constant expressions before it is necesary! Doing so can easily result in loss of accuracy when doing subsequent numeric computations, due to roundoff error in the approximated coefficients.

Leave coefficients as exact values as late as you can. It may prevent roundoff error from hiding roots, or finding true extrema, and it might even allow useful symbolic simplification.

In this example it looks as if the supplied expression contains a mix of exact names (ie, x) and floating-point coefficients. It seems possible that some (earlier) representation or characterization might be possible in which a wealth of multiple roots could be ascertained.

Below I use Maple 2019.1.

Download solve_equation_ac.mw

Calling fsolve with a maxsols option (alas, undocumented) is just a hook to NextZero. It's an alternative to Student:-Calculus1:-Roots(...,numeric) which calls fsolve recursively.

Also, we can note that a 10-digits approximation to an actual root can possibly produce a large residual (forward error). That can happen simply due to the fact that the root (or the coefficients) have been already rounded. 

In Maple 2015 you'll need to account for the special-evaluation rules which Explore has on its first procedural parameter (ugh).

Here is one way that seems to handle your posted example, in a procedure. I used Maple 2015.2. Here I deliberately stuck to your original approach.
Explore_Procedure_ac1.mw

ps. I mean no offence, but I have reservations about this whole approach, including picking apart RVs. (I don't understand what great convenience that brings over passing around a distribution name and parameter names, at the risk of complicated and IMO hazy mechanisms.) And to go to such efforts, while global :-x must still be unassigned, etc, seems awkward to me. Perhaps I don't properly understand how this OBSERVE procedure is intended for use.

The command with is not intended to work inside a procedure body. It's Help pages documents that clearly, with examples. That is the primary cause of the error.

I have changed your definition of PR to utilizes the uses syntax instead.

does_not_evaluate_ac.mw

Since you're using Maple 2019 you might find its new Calendar package easier for those computations (eg. date differences).

It is undocumented and not widely known that the caption string of a Button Component can be set using a reasonably convenient subset of HTML.

This attachment shows font size control in two such ways. I used Maple 2019.1.

Download caption_html.mw

You can use similar techniques to control qualities such as text color, bold and italic, etc.

I am not sure what is the extent of this functionality.

If you pass the inequalities to solve in an And call (as opposed to the more usual set)  then the result will be a RealRange which pretty-prints in a traditional manner with brackets.

Here's your example, as well as some conversions back and forth.

Download solve_RealRange.mw

Your question is unclear.

Are you asking for axis labels and axis bars but with no axis tickmarks?

Or are you asking for axis labels with neither axis tickmarks nor axis bars? That is not possible in the strict sense, since the labels are part of the axes (as a whole, to the GUI renderer) and there is no syntax for omitting only the axis bars.

While you may not be able to get rid of the axis bars themselves while retaining axis labels, but you can make the axis bars thin and white and less apparent under no light model.

Personally, I don't see much point to having axis labels without any axis bars since in that situation it is visually unclear as to where the labels lie spatially, upon rotation. Without the axis bars there's little visual cue (apart from what the surface might convey...)

Download axis_suppr.mw

Alternatively you could give up on axis labels and get rid of the axes bars altogether. But if you instead utilize textplot to mimic labels then they won't always jump to the fore (as axis labels do) upon rotation. I haven't shown this.

Below I am talking about the dimensions of the inlined plotting window in which the plot appears (who's borders one can drag manually with the mouse pointer, to resize).

In unmodified Maple 2019 and earlier it cannot be done using the size option directly (in 3d plotting commands).

But it can be applied to the plot after the fact. For example,

restart;
setsize:=proc(P,sz::[posint,posint])
  op(0,P)(remove(type,[op(P)],'specfunc(ROOT)')[],
          ROOT(BOUNDS_X(0),BOUNDS_Y(0),
               BOUNDS_WIDTH(sz[1]),BOUNDS_HEIGHT(sz[2])));
end proc:

foo := plot3d(cos(x/10+y/10));

setsize(foo, [600,600]);

Is that good enough? An alternatve is a code snippet that could go in your personal initialization file, the effect of which is that the option size might be used directly from within plot3d, plots:-display for 3d plot, etc. (I recently figured a small number of modifications that might allow this...)

[edit] Another variant on the above code snippet might be,

setsize:=proc(P,sz::[posint,posint])
  op(0,P)(op(subsindets(P,'specfunc(ROOT)',()->NULL)),
          ROOT(BOUNDS_X(0),BOUNDS_Y(0),
               BOUNDS_WIDTH(sz[1]),BOUNDS_HEIGHT(sz[2])));
end proc:

One could also qualify the parameter P of that procedure with a type, eg. specfunc({PLOT,PLOT3D,_PLOTARRAY})

You won't be able to do another computation in this same worksheet while this clock code is running.

Download clock.mw

Use the so-called 2-argument calling sequence of the eval command.

The purpose of that functionality is to allow you to evaluate a formula (in your case, simply L) at the values denoted by the equations.

eq := L = 2/3:
eval(L, eq);

                      2/3

eqs := {L = 2/3, x1=blah, x2=foo, x3=bar}):
eval(L, eqs);

                      2/3

eval(x1, eqs);
                      blah

eval([L,x1,x2,x3], eqs);
    
              [2/3, blah, foo, bar]

eval((L+x1)/x2, eqs);

                    2/3 + blah
                    ----------
                       foo

This is a common programmatic operation and, as you've noted, an important one.

This is superior to calling assign on eqs (which assigns the values to the names but prevents immediate, subsequent use of those names as unassigned parameters unless you subsequently unassign them).

This use of eval is also superior to picking off the right-hand side of any of the equations in a set by its position (which can change if you choose different names for the variables). Ie,

op(1,eqs);

                   L = 2/3
rhs(op(1,eqs));

                      2/3

You can plot a surface with an image on it, which is the closest to "texture mapping" for Maple of which I'm aware.

In recent versions you can, for example, use the image option on a plotting call like plot3d.

In some versions for which the image option is not yet available, you can do this sort of thing manually. (The implementation in that old Post are very similar to what the image option does, in essence. There are several links there to yet more old Posts, on related topics. The newer colorscheme option's implementation is also related.)

I do not know the specifics of how the Standard GUI renders plots (jogl, opengl, etc) so I cannot state specifics about "texture mapping" technically.

(As an example, this site had this recent post on the image option.)

Your problematic example with discont was fixed in Maple 2018.0.

Download polar_pw.mw