What kind of coefficients do the polynomials have? Real exact rationals? Real floats? Exact radicals like sqrt(2)?

If all the coefficients are real and rational (or float) then you could use RootFinding:-Isolate. If they are real exact radical (or even just of type realcons) then you could apply evalf (and possibly fnormal) to get them all as real floats, and then use RootFinding:-Isolate.

Why not show them to us, in an uploaded worksheet?

Are you saying that your difficulty is with the white border around the 3-D plot window, because your figure is not square (e.g. tall and thin)?

@mapleatha In general there is no mechanism to instruct the solve command to return only purely real solutions.

In some special cases there are ways to get what you ask.

One way is to sieve out the non-real solutions, after the fact. This is only as good as the mechanism chosen for determining whether an expression is purely real. Quite often the is command can succeed (sometimes with assumptions on any additional parameters -- ie. non-solving-variables). Note that since is can return FAIL you have to decide whether to allow such a FAIL to produce false positives or false negatives.

This approach overlooks any means (if such even exists) to obtain only purely real solutions more quickly than all complex solutions are obtained.

restart;
p:=x^3-x-1:
sols:=[solve(p,x)]:
evalf(sols);
    [1.324717958, -0.6623589786 + 0.5622795125 I, -0.6623589786 - 0.5622795125 I]

rsols:=remove(is,sols,Non(real)):
evalf(rsols);
                                 [1.324717958]

In the case of a system of polynomials (with real, rational coefficients) you can try the real option to the solve command. Eg, compare,

forget(SolveTools); solve(x^3-x-1, x, allsolutions);

forget(SolveTools); solve(x^3-x-1, x, real, allsolutions);

If you have a system of polynomials with rational coefficients then you could also consider going straight to the SolveTools:-PolynomialSystem command, utilizing its domain=real option. Note the if you have a system of polynomials with real floating-point coefficients then you might choose to convert to rational so that you can try this approach.

In some cases supplying additional inequality bounds to the set of equations can help solve obtain only purely real solutions. This doesn't always work. Sometimes it interferes with solve's ability to produce all solutions.

There is also a package RealDomain, which exports its own RealDomain:-solve commmand which attempts to work only over the reals. There are many examples which defeat this, however, producing either some non-real results or missing some purely real results.

@Christopher2222 That will incorrectly remove too much. Consider the roots of a cubic, in the case that all are purely real but when expressed in radical form containg the imaginary unit.

For the purpose of this sieving I'll leave aside the fact in this case a trig representation, without the imaginary unit, might be attained using evalc. The key point is that the mere presence of the imaginary unit (in a particular represetation) does not mean that the expression is non-real.

restart;
p:=x^3+6*x^2-10:
sols:=[solve(p,x)];
remove(has,sols,I);  # oops, removes them all

evalc(sols);
evalf(evalc(sols));

remove(u->is(u::Non(real)),sols);

@Cryme One might hope that D(g) would return unevaluated for complicated procedures that it's unable to handle. Unfortunately there are cases where D gets confused.

Going back to your earlier query for a moment, here's my prefered approach to that issue. It consists of constructing the procedure so that it returns unevaluated when its argument is not of the right type (eg. not numeric, or not realcons, etc).

The idea here is that calling g(y), for y an unassigned name, will always just return g(y) itself. The effect is that g(y) can be passed to plot just as an expression, rather than as g the operator.

This version of g also gets handled better by D.

restart;
f:=x->ln(x)+x:
g:=proc(y)
  if not y::realcons then
    return 'procname'(args);
  end if;
  fsolve(f(x)=y,x=1..10);
end proc:
g(2.3);
D(g);
plot([g, D(g)], 1..10);
g(y);
plot([g(y), D(g)(y)], y=1..10);

In future please ask in a new thread as a new Question, rather than tacking on your queries as Comments on old threads. Also please either inline valid plaintext code or upload a worksheet (big green arrow), instead of pasting in images. Nobody enjoys having to retype examples. Thanks.

@Cryme The central problem in your first attempt was the usual (but here premature) evaluation of g(y) as the first argument to the plot command.

Your intermedPlot procedure is an unnecessarily contrived way of dealing with this, IMO.

Simpler would be to avoid premature evaluation, with either of these minor changes to your original.

f:=x->ln(x)+x:
g:=y->fsolve(f(x)=y,x=1..10):

plot('g'(y),y=1..10);
plot(g, 1..10);

I recall now that I'd tried method=RC for RootFinding:-Isolate for your earlier related Question, and it took long enought that I didn't let it finish.

[edited] I wrote something (now deleted) about obtaining better performance with the digits=5 option to RootFinding:-Isolate. Unfortunately I forgot that I'd previously computed with default options in the same session, and so the speedup I mentioned was due to cached results. Doing a clean run with only the digits=5 call took as long on my machine (16.5 minutes) as without it. Sorry for the noise.

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.