@John Fredsted No worries. My version involved convert(cos(16*x1),expln) and I ought to have noticed that is exactly 0. It would be more apparent if I'd just done expand(cos(16*x1)) instead. Then it would be even more like member vv's expand(cos(16*x1)) which also produces 0 immediately. (I had to edit my previous comment too, to apologized for the close but unintentional duplication of approach.)

And your first observation can be had directly, as expand(cos(8*x1)) which returns sqrt(2)/2. So that too is in the same camp: noticing that cos(N*x1) equals something with known useful properties (for the trig inversion).

To me these "fortuitous" first steps are even more ad hoc as finding the values of the introduced parameter in the latter step.

@Markiyan Hirnyk Thank you, that sets the bar higher.

@John Fredsted That's an interesting idea, although there is still the matter of determining the values of the introduced parameter (for you n=2 and -1 for the boolean, and for me below _Z1=7). And the choice of application by `cos`, and the choice of the scalar multiple, is also to be considered. But thanks for the idea. Here's another way to utilize it.

[edited] After I did the following implementation I reread the whole thread and realized that the code below is the essentially the same kind of approach as member vv's Answer. That duplication was completely unintentional, and my apologies to vv!

restart;

x1 := arcsin(1/2*(2+(2+(2+2^(1/2))^(1/2))^(1/2))^(1/2)):

K:=simplify(solve(cos(16*T)
                  =radnormal(convert(cos(16*x1),expln)),
                  allsolutions));

                  K := 1/32 Pi + 1/16 Pi _Z1~

v:=indets(K,name) minus {constants};

                         v := {_Z1~}

eval(K,v[1]=7);

                            15 Pi
                            -----
                             32

@vv That's the kind of thing I've been wondering. It would be sad if one had to resort to ever more nestings like `expand(combine(...))`.

On the one hand it seems Maple has difficulty simplifying mixed functional domains (e.g. arctrig and complex radicals). 

It may be that part of the difficulty is that `expand` and friends are hitting everything. Perhaps they could be used more selectively (e.g. frontend'ed).

I've see `solve` spit out arctan of complex radicals, quite often when given trig equations that I believe could be better handled by more examination of the periods of the individual trig calls contained.

@tomleslie Thanks, though I was trying to avoid `identify`, with the wording, "exact, symbolic steps".

@vv Thanks for looking, but as you've likely surmised I'm really after some kind of systematic approach where the target is as yet unknown.

@erik10 I am quite in agreement with you: there's quite a bit of improvement needed for the GUI, in terms not just of rescaling for high-res displays but also for consistent rescaling of embedded components and their associated text.

I'm not trying to suggest that things already work fine. I'm just trying to point out a few things that might possibly help you mitigate the difficulties now.

By the way, there have been quite a few reports by Danish users (mostly students) on this site, over the years, about corrupted worksheets. One aspect that recurs may be the presence of special text characters (eg. Danish), possibly linked to errant escape-characters. But I've been wondering whether the common presence of (not small, always) inserted images in the documents might not also be part of the problem. It would be a good thing to see such problems resolved.

@erik10 

Explicitly supplying some other value for the size option should already override whatever has been set using plots:-setoptions. That's a nice thing about plots:-setoptions, it allows you to set preferences, which can then be easily overridden at any time, with the usual command calls.

Also, the size=list option can be utilized on a call-by-call basis, with different values (as the first float in the list, designating the proportion) as desired.

When you write of "images" I'm not sure whether you mean images as backgrounds to plots, or inserted from the main menubar, or embedded using ImageTools:-Embed, or as a Drawing (canvas).

For images used as the background for 2-D plots, those don't respect plots:-setoptions with the size option, which I think is a good thing. But an explicit use of the size option in a plot command can still override the original dimensions of the image. Eg, using Maple 2016.2, with each of these lines in its own execution group, say,

restart;
plots:-setoptions(size=[300,300]):

img := cat(kernelopts('datadir'),"/undercarriage.jpg"):

# Good. Image file is 600x400.
# Should not adhere to setoptions preference of 300x300.
plot(background=img,axes=none);

# Good. Respects the specified size.
plot(background=img,axes=none,size=[300,200]);

# Good. Picks up setoptions preference of 300x300.
plot(sin(x),x=-Pi..Pi);

For images inserted using the main menubar's Insert->Image action, you could insert them into a single-row, single-column GUI Table, without exterior borders. By right-clicking on that Table you can set its properties. That includes setting it to be a fixed properotion of the GUI window's width (default is 100%). You can also center that borderless Table. As long as the original image width is greater than that proportion of the window width then the image will be zoomed to that dimension. So just make sure that the image is a wide as the maximally needed case.

For an image embedded with the ImageTools:-Embed command you can also right-click and change the Table's properties to a specific fixed proportion of the window width. You can also center it, eg, using the main menubar's Table->Alignment->Table->Center . (It would be nice if that command got the nicer options to do all that programatically like DocumentTools:-Tabulate can, or alternatively if DocumentTools:-Tabulate got the functionality to handle Array-based "images".)

Unfortunately the Drawing canvas does not seem to rescale automatically when placed within a GUI Table whose width property is set to a fixed proportion of the GUI window's width. Ie, objects drawn don't rescale when the GUI window is resized or maximized. That's a pity.

The size option for 2-D plots can also be set as a proportion of the Maple GUI's windows (working area) width.

For example, if you put the following line in your initialization file then all 2-D plots should by default be rendered in 40% of the width of the GUI window's work area.

plots:-setoptions(size=[0.4,1.0]):

Moreover that information is part of the actual PLOT structure, and so it should be respected when someone else re-opens the document (without re-execution).

The second value of 1.0 means that the height is set the same as the width (when scaling=unconstrained).

In other words, the size option is not just restricted to a list of integer values like [400,400] which is a pixel-related setting.

What you've shown looks like a PLOT3D function call (which is the structure in which Maple stores the details of a 3D plot).

But such a structure should be in all-caps, not lowercase. Maple is case-sensitive, and so what you've shown is invalid.

Also, it's a poor (or at best old-fashioned) book that needs to resort to having you enter such a structure by hand, directly. Using plotting commands such as plots:-polygonplot3d, plots:-display, plottools:-polygon, etc, are by far the more usual ways to construct such structures.

Did you have trouble finding those kinds of command (intended for constructing such structures) in Maple's searchable Help system?

@DaGu Perhaps you'd be interested in a scatter plot, with (Lowess) smoothing.

@thuannguyen 

Enter it as C.A not as C*A. 

Do you not see that those are typed differently, using different keystrokes?

It looks like you entered it as C*A instead of C.A . The former of those involves the star (asterisk) on the keyboard, while the latter involves the period.

Notice that your typeset 2-D Input shows an interpunct (raised dot) rather than a period (baseline dot).

@Carl Love I saw the plaintext attempt to define the proc, but asked for a sheet because I didn't see a call to it which would produce the purported followup screen shot.

The source has lots of errors. Eg. several instances of plain = instead of := for statements that seem intended as assignments. And it's not wholly clear to me what lowercase t is for.

I agree with you that the OP should state the underlying goal, and differential equations if relevant.

@berkeliox It is likely that you've done something differently now (if only because your screenshot shows more outputs apparently from within the proc body, other than the final plot call).

This runaround guessing could be avoided if you were to upload your actual worksheet file. For that use the big green up-arrow in the editor here, when adding another followup Comment/Reply.