I agree, the new pretty-printing of Units without fencing is much less useful. Having the only visual cue be the use of an upright roman font is inadequate.

My first thought earlier today was to use a print-slash extension procedure (like Carl has suggested, although I was using the original 2D Math double-brace entities rather than square-brackets).

What I noticed was that upon copy&paste the pretty-printed thing was being copied instead of the value. And that's likely to be awkward.

If the pretty-printed result generated by `print/Unit` is a Typesetting beastie then I think that the copy&paste might work. But it's slightly tricky to get the fencing right, and there are some additional semantic info bits in the usual typesetting of Units:-Unit calls that might be tricky -- the goal being to make the rendering keep the fencing, respect copy&paste, and keep other usage(!?) cases OK.

I'm a little busy right now, though...

[edited] I could add that I'm not aware of a way to alter/revert the behavior using Typesetting:-RuleAssistant or Typesetting:-Settings. And the new behavior appears to be purely a GUI rendering thing, by which I mean that the structure produced by the Library's Typesettting procedures remains the same. So it's a matter of how the GUI chooses to render the structure. And I don't see any item in the GUI's preferences/options to control/revert the behavior.

Also in Maple 2017 there is an existing system Library procedure `print/Unit` (which is not protected, though it ought to be!), and a replacement might be better constructed as a revision than just an ad hoc rewrite... 

@brian bovril What I meant was that the only way I know to programatically build and insert a hyperlink into a worksheet is to use such DocumentTools commands and mechanisms. It cannot be simply printed like regular output, in the way that executing the simple input sin(Pi/2) returns and prints 1 as the output.

Now, let's talk syntax. These commands build a worksheet programmatically, and then embed it right into your currently open worksheet. So the stuff that I assign below to name xml has to have the right structure. That means that Worksheet has to be the outermost call (and it can only appear once, as that outermost call). Try this,

restart;
with(DocumentTools): with(DocumentTools:-Layout):
HL := DocumentTools:-Layout:-Hyperlink:
xml := Worksheet(Table(interior = none, exterior = all, hiddenborderdisplay=never,
                       widthmode=pixels, width=600, alignment=center,
                       Row("Minesoda SL"),
                       Row(HL(Font("7/11/2017",'style'=':-Hyperlink','color'="Blue"),
                              'linktarget'="http://www.maplesoft.com")),
                       Row("Summary Report"))):
InsertContent(xml):

In the examples that I sent you for your larger project, I believe I put in as many Column() calls as the Rows have entries (spanning cells). I think that's prudent practice. The same for wrapping single entries in calls to Row within their own Cell calls. (Rows can have more than one Cell.) There is some smarts in the Row and Table constructors to figure out some of the bookkeeping on their own, but my preference in to have all Column, Row, and Cell calls be explicit.

I also like to indent my code, for legibility. You don't need to follow my indenting style, but you ought to have some style that helps you code (and stick to it consistently).

restart;
with(DocumentTools): with(DocumentTools:-Layout):
HL := DocumentTools:-Layout:-Hyperlink:
xml := Worksheet(Table(interior = none, exterior = all, hiddenborderdisplay=never,
                       widthmode=pixels, width=600, alignment=center,
                       Column(),
                       Row(Cell("Minesoda SL")),
                       Row(Cell(HL(Font("7/11/2017",'style'=':-Hyperlink','color'="Blue"),
                                   'linktarget'="http://www.maplesoft.com"))),
                       Row(Cell("Summary Report")))):
InsertContent(xml):

BTW, you can put a Table call within a Cell of another Table. This can get you nested Tables.

Do you want map(F[n],Q[n]) instead, which in modern Maple could also be done as F[n]~(Q[n]) ?

If that's the case then you'd need to pass Q in as a list of lists, eg, Do( [ x -> x , y -> y^2] , [ [0,1,2,3] , [4,5,6,7] ] ) .

@jnjn0291 In case anyone was wondering whether all the exact eigenvalues are real and non-negative for all x,y real. (This relates to our ignoring the imaginary components in the floating-point approximations.)

Download cplx_semidef.mw

Just a note: Your second working example, using an anonymous procedure, is parsed OK as 2D Input but not as 1D Maple Notation.

So if you are going to enter it here as unformatted text, then you might want this instead:

s:=0: seq(proc() global s; s:=s+i end proc(), i=1..10);

@mapleatha One of the things I was trying to get at before was that it often makes sense to write code "defensively (in the sense of "defensive driving").

So, for your case, before one tries to access op(n,g) it can be prudent to check that type(g,`+`) returns true.

@mapleatha As mentioned, op(n,g) exists for all n from 1 to nops(g).

That's what nops(g) means -- the number of operands of g.

The nth operand exists if n is between 1 and the number of operands.

For a sum of terms, the terms (summands) are the operands.

So yes, a sum of q terms has q operands. So the nth operand exists for all n from 1 to q.

@jnjn0291 

You're most welcome. I suspect that the people who answered enjoyed the programming challenges of your problem.

I noticed that the display of the upper value of one of the eigenvalues is about 1.999999991 and not quite 2, which presents some difficulties in 3-D plotting as a surface so close to the surface for eigenvalues lambda=2. I opted for transparent filled regions, but there are other ways. For example the boundaries could be wireframe instead of plain surface. Or the corners could get vertical darker line segments. If you want it to look different then please explain just how.

And here I add in filled regions for the spectral bands.

eigenspect2.mw

@mapleatha You can also use the Typesetting:-Supress command to veil the bracketed arguments of the function calls.

(This again was Maple 16.02, but it may well work the same in old Maple 13.)

You only need make the calls to the interface and Typesetting commands once (at the start of the worksheet, say), once you've decided on the format you prefer. I have them interleaved with the statements containg diff calls just because I was illustrating various choices of output format.

Download diff_typesetting_suppress.mw

In Maple 2017, with the new default of extended typesetting level, the commands would be just this:
 

Download tp_prime_2017.mw

@Kitonum By giving `option remember` to procedure AllRoots there is a speedup by a factor that is close to the number of seperate surfaces generated.

(Using `option remember, system` would allow eventual collection of remembered values, but it might incur gc() overhead between the multiple calls to generate the surfaces in the since plot3d call.)

The end result is just a tad faster than the code in my Answer.

I also added the option `complex` to the call to fsolve, because there is a problematic central region for one of the higher surfaces where the imaginary components come out not quite as zero (and that confuses AllRoots into grabbing from the wrong root). One could also just apply Re, to get the upper surface without a hole (as I did in my code, which I think may be where it runs a tad slower).

lambda_remembered.mw

@John Fredsted 

That is in a similar vein to the code I gave. I realize that John is addressing the followup question about session dependent ordering of the multiplicative terms (so what I write below is not criticism, but notes for Taro the OP).

[deleted: something wrong that I wrote.]

I tried to do it efficiently with just one selectremove, instead of a select and a remove. But that is not very important. I like that you used select directly on the numerator, while my code was busy fiddling with lists of multiplicands.

I note that your code would match a multiplicative term in the numerator such as sin(Omega), while I strived for more relevant targetting of a term which is polynomial in Omega (or mu) with degree at least one. For the current example the only term in the numerator that matches does happen to have that property, so for this particular example this doesn't matter.

I might also note that selecting according to only Omega (or only mu) might not always get to the mark. A change to make one of the factors be (K*Omega+1) instead, say, can illustrate this. That's why I tried to look at all the multiplicands in the denominator (as itself a product of names).

div2.mw

There are lots of ways to make examples which stymie both codes, of course.

I mention this all just for Taro's understanding.

If I knew this at some point in the past then I'd forgotten it.

The plot command does not always apply evalf to the end-points, when not operating in evalhf mode.

Instead, it can try and use the exact end-points for evaluation of the expression/procedure, and only generate floating-point values from such results.

This is why, when Digits is high, the call plot( (1-x)^(10^9), x=0 .. 10^(-15) )  can goes away for a long time, or hit the stack-limit.

So perhaps the simplest successful variation here would be to use greater working precision as well as floats for the end-points, eg,

restart;
Digits:=20:
plot( (1-x)^(10^9), x=0 .. 10.0^(-15) );

That also explains why the first variant I gave in my Answer also works, since its operator turns its argument x into a float before computing the formula.

restart;
plot(x->eval(evalf[20]((1-x)^(10^9))), 0..10^(-15))

While surely it's easier just to use floating-point values in the supplied range, it's also possible to build a coercing operator from a pre-existing expression.

restart;
expr:=(1-x)^(10^9);

f := unapply( expr, [x::coerce(float, (s::realcons)->evalf(s))] ):

Digits:=20:
plot( f, 0 .. 10^(-15) );

I find it interesting that the expression b is smaller than the expression a according to some metrics, but not perhaps by that used by simplify(...,size).

restart;

a := rho^(epsilon-1)*a__01^(-k)*(N__E2/Omega+N__E1*mu)*(K+1)/(mu):
b:=rho^(epsilon-1)*a__01^(-k)*(N__E2/(Omega*mu)+N__E1)*(K+1):

length(a), `simplify/size/size`(a), MmaTranslator:-Mma:-LeafCount(a);
                            99, 60, 26

length(b), `simplify/size/size`(b), MmaTranslator:-Mma:-LeafCount(b);
                            90, 63, 24

c:=simplify(a,size):
length(c), `simplify/size/size`(c), MmaTranslator:-Mma:-LeafCount(c);
                           103, 55, 26

lprint(c);
  rho^(epsilon-1)*a__01^(-k)*(N__E1*Omega*mu+N__E2)*(K+1)/Omega/mu

I don't think that length would be a good metric, but I've wondered about how useful it might be to have simplify(...,size) optionally use LeafCount.

@John Fredsted Your suggestion to use applyop is of course simple and effective, and I apologize if I sounded at all officious. And since we only have the single example to handle then obtaining the target seems just fine.

I was mostly just wondering how "it" might be approached more generally, but in truth all I really figured out was that the single given example/target pair doesn't really specify thoroughly what "the" more general goal might be.

note: the boilerplate conditional checks in my code are somewhat mirrored, in a direct coding using say applyop or op, by the implicit assumption that the original expression is a product of terms. Again, this aspect may not matter at all to the OP with just this single example.