@claus christensen Sorry, I don't really understand how your last comment relates to my suggestion because I don't have any idea how your intended application is going to function.

There is an undocumented Hide export of the Layout subpackage, which you can use to clobber off the display of Execution Group Boundaries. Note that it will affect all Execution Groups in your sheet. Also, since its not a package export it has to be called with its full command name. And as far as I know there's no programmatic way to turn it back on in the same sheet. I don't really recommend this and, again, I'm not sure how it solves your "problem" properly because I don't understand the problem.   display-problems_Hide.mw

Another way to insert content without a border is to use a Table (whose borders you can suppress from display). I prefer this to the above. display-problems_Table.mw

This might be an appropriate time to mention that in general I've found that it often works out better for interactive applications to use elements from the Components subpackage, rather than only Layout elements. For one thing, that allows you to insert say a PlotComponent just once and then have some Button/Textarea/MathContainer/etc be used to update it with a new plot as the math example is switched/changed in-place. display-problems_PlotComponent.mw

You don't have to build your application with these programmatic commands (and I apologize if you know this already). You can use the palette and menubar to insert embedded-components and GUI Tables, and adjust the code that runs below them using the mouse. This is often convenient to prototype interactive applications, and indeed many people only do this. I personally find that even when I prototype in this way I often still want to write fully programmatic code that generates the same whole application -- because I prefer to have my applications as plaintext source code against which I can do version control.

[edit] The Input/Output Layout elements (within Group/Document elements) can be useful for constructing purely expository material, while the Component elements provide an interactive facility. It may be that you want to reconstruct such expository material when the particular math example is changed, and then re-insert the whole application in-place within the same Task Region. That's a bit advanced, but could be quite slick. A way to do that would be to write re-usable procedures for full reconstruction, based on the new example as argument. A master procedure which utilizes the reusable content functionality of the InsertContent command (its replaceid option) could then re-insert the wholly new example including new expository material as well as the same Button/etc that triggers the rewrite.

@wndrslope This thread is 8 years old, and the issues/causes in that Maple release may be different from those of your problem.

So post your example as a distinct new Question.

And upload your document, using the big green arrow. Don't try and mimic your 2D Input as pasted plaintext or an Image.

@tomleslie This behavior is new to Maple 2017, I believe. (Bug reports submitted.)

Download 2017_roundoff_2D.mw

If you wish to test a name like _Z1 for assumptions (or otherwise manipulate or utilize same in some computation) then you can use the command getassumptions. For Carl's example,

getassumptions(_Z1);

               {_Z1~::integer}

I have submitted a bug report.

Last week I was having problems getting the output of uploaded worksheets to display inlined on Mapleprimes. Now it seems to work, but no longer properly respecting the width of the exported .mw file (a GUI preference).

@tomleslie I am no longer surprised by coincidences.

Just yesterday I found out that in Maple 2017 the parsing of 2D Input had changed, to the effect that certain infix arithmetic statements would no longer automatically simplify as the had in prior releases.

The upshot is that several of your Answer's claims are not true of 2D Input in Maple 2017.

I consider this a significant compatibility issue, and I was thinking of making a Post about it. Interesting examples include addition of identical function calls, where the procedure call's evaluation induces side-effects  (e.g. assignment to globals, in place updating of Array arguments, etc).

Here are basic examples, which one can do in both 1D and 2D Input modes in Maple 2017:

  sprintf( "%a", 'f() + f()' );

  lprint( 'f() + f()' );

  'f() + f()':

In 2D Input in Maple 2017 those become calls to the prefix `+`, containing two calls to `f()`, instead of automatically simplifying to `2*f()`.

Of course there have long been other ways to prevent some relevant automatic simplification of such expressions, including overloading arithmetic operators like `+` and `*`. (Even merely loading the Units[Standard] has had similar effects on automatic simplification.) It's usually awkward to set up but, depending on the precise details of the OP's goals, it may be possible to come up with a solution.

@mschneider You write as if that bolded collection of characters is a thing.

Is it merely what you would intend as typed into a Maple interface?

Or do you expect it to be an expression or string or compound name (perhaps even the assigned value of some variable/name in Maple)?

The difference between those can make a big difference to the answer.

How do you expect that structure to exist in Maple without the like terms combining?

What version of Maple are you using? Which interface? (eg. Standard GUI, Maple Cloud, Classic GUI , command-line shell?) Which input mode? (eg. 1D plaintext,  2D Math) It might well make a difference to the answers.

@arianbig The suggestion is that res1 mistakenly contains the function call

 cf[-1](-1.833333334)

instead of, say, the product,

 cf[-1]*(-1.833333334) .

It doesn't make sense to add terms like cf[-1](-1.833333334) and 68.25827819*cf[1] , where cf[-1] is an unassigned name, and expect fsolve to do something useful.

You likely omitted a multiplication sign (or a space if you are using 2D Input and replying on that to denote multiplication implicitly) somewhere earlier in your code that contributes to the construction of res1.

If you upload your full worksheet which constructs res1 then we might be able to point you to the location of such a syntax mistake. But if you don't then we can't.

I'd like to clarify some apects.

This is not a question of using 2D Math versus 1D Maple notation. Rather, it's a matter of using Clickable Math (like the right-click context menus) versus programming. In a previous Question the submitter has declared some preference for the clickable approach.

The original Question's document has a call to the smartplot command, (veiled) as the result of doing a context-menu action. Tom Leslie's Answer consists of handling the units with a programmatic approach.

Whether invoking smartplot, the new (2017) interactive plot-builder, or the older (Maplet's based) plots:-interactive command, there is a general weakness in the automatic handling of units in plotting.

What happens if (after re-executing the whole sheet, so as to get the various quantities assigned) you do the following:

1) Edit the lines with the problematic plot calls, and terminate them each a full colon. Then press Enter.
2) Edit those same lines again, removing the trailing colons (so that the plots are once more shown).

The idea is to remove the output from those lines, and then re-execute.

It's possible that some rendering qualities on the float tickmarks are suffering from "plot persistence". Temporary removal of plot output from a paragraph/rexecution-group can get rid of some persisting qualities.

@maple2015 It looks like there is a local minimum (of both real and imaginary parts) at omega=0. But the real part is not zero there, for your given expression, being something close to 0.09 or so AFAIKS.

It doesn't help that your expression looks like it has had evalf applied to it to early. That may be making further numerical and mixed symbolic/numeric computations more awkward. It might well be easier if you gave us the whole original computation, in which it might make things easier if 2*Pi and other constants and so forth were not turned into floats.

@Ramakrishnan What do you mean by "difficulties"?

Do you mean that it just doesn't work?

Or do you mean that the original display with the "->" arrow gets replaced by something like, say, proc(...) option operator, arrow; ... end proc when pasted in? That alone should not prevent it from functioning, and is just a 1D Notation/lprinting/formatting thing.

No, my example Does Not require you to load DocumentTools or Statistics or anything like that.

You've written two statements above: an assignment to eq21 of a collect call on eq20, and equation with q(x,s) on its LHS.

You didn't provide the value of eq20, so naturally we cannot re-execute that assignment statement properly.

Are you saying that equation was the output of executing the first statement, and that this is the "expression" you want further simplified? If so then something seems amiss because applying that very same kind of collect call to the given equation does further simplification of the coefficient in question.

simp_example.mw

Also, when you say that you want further simplification of just one "coefficient", does that mean that you want all other terms left untouched?

Altogether I find it difficult to see what you are asking for, and what your expressions are, and what you hope to achieve.

@mikemeson Why did you not try my suggestion? For your data it would simply be something like the following,

plots:-display(
  surfdata( Op1, 25..35, 25..35 ),
  surfdata( Op2,-25..-10, -25..-10 )
);

That shows the two surfaces, respectively above the two different x-y domains specified.