@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.

A minor point is that the collect command allows for an optional argument, to specify post-processing action on the coefficients. So it can be done in one step like so:

collect( q(x,s), [exp((lh-x)*sqrt(s+thetac)/sqrt(Dc)),
                  exp(sqrt(s)*(-lh+x)/sqrt(Dp)),
                  exp((-2*lh+x)*sqrt(s)/sqrt(Dp)),
                  exp(-sqrt(s)*x/sqrt(Dp))],
         simplify );

Also, mapping simplify to the result of the shorter call to collect could in general affect not just the coefficients but also all of the collected subterms (which might possibly not be wanted). That doesn't happen here, however.

For this example it also turns out that the subterms to collect are the only instances of function calls to exp in the expression. So for this particular example it can also be done with a little less copy&pasting, as:

collect( q(x,s),
         indets(q(x,s),specfunc(exp)),
         simplify );