@Gabriel Barcellos As you mention, this only affects the latter part, whose only purpose was to reformat the rational coefficients just as you wanted. The answer in the first part is already correct, and in trigh rather than exp calls.

I had shown 1D Maple Notation code. Not all such code can be simply copy&pasted in as 2D Input.

In particular I had used the infix form of an inert operator call, eg.
    foo %* bar

That infix syntax is not supported at present in 2D Input mode. But you can instead use the prefix form call in 2D Input mode, eg.
    `%*`(foo,bar)

Download solve_trigh_2Dmath.mw

@Thomas Dean I'd prefer my second way, which works even in old Maple 16,

Download ut_M16.mw

@srwarner 

You should provide at least one complete example, showing all all its programmatic input, and describing clearly all that you want to be able to accomplish programmatically. If it's only a toy example then you should describe the broader class you want to handle.

This is a long Question thread, but I haven't seen any such clear and comprehensive description here.

@srwarner 

Download inequality_basic.mw

@Rotcev Each of us was a novice user at some time. Your questions are welcome. This is a good question.

But I'm not sure that I've properly conveyed the difficulty to you.

The central issue here is that the following Maple expression will not persist, using the ususal multiplication and power calls:

     (2*a*Pi)^(1/4)

As soon as that is entered or arises during a computation the factor of 2^(1/4) is separated from the rest.

That is a kind of canonicalization that assists Maple's performance. It happens automatically. It cannot be prevented by using uneval-quotes.

You can, however, constructs something else (an inert form, say) that happens to render as you want. But it would not be the same object as your original expression, and you could only interact and further compute with it if you first turned it back into the form that you don't like. It would only be useful for display purposes. Is that what you would like?

@rzarouf You can simply use strings for the legend items, and avoid any clash with the command names.

The following attachment also does the "x" and "y" axis labels.

[edit] I also changed the return value of your P0 procedure, so that the order of the plots and legend items is consistent, by using a list rather than a set. Adjust the list, to force the order of your choice.

rzarouf_03_ac.mw

ps. I only used eps=1e-5 before because all these hold:
   1) Your question didn't show us what value you intended for it.
   2) The value of eps (and the appearance of the curves) is not
       relevant to your whole size/scale/ranges question.
   3) It runs faster.

By the way, I suspect that the execution speed of your code can be improved. Unfortunately I don't have much spare time to do that right now.

When I introduced units-handling into my phasor stuff I got a little over-enthusiastic with some (perhaps dubious) idea of temporarily converting floats to exact rationals.

Your example shows a case where it incorrectly handles that: ie. failing to turn such rationals back into floats.

The whole phasor-as-object thing was mostly my investigating whether objects as algebraic expressions (in the Maple type sense) was generally workable. So I got a little "creative" in spots.

I can try and fix up my phasor code, especially with respect to units & floats, and get back to you here about it. Unfortunately it won't be this week, and it'll take some time that I don't have available right now.

As far as initialization goes, would you rather,
1) put a call to read this (from a source file) in an initialization file
2) Save it into its own .mla archive and,
  2a) adjust libname to see that, in an initialization file
  2b) place that .mla in a special location that gets added to libname automagically
?

Thanks for your example.

@Christian Wolinski I don't agree with this claim, and I don't think that the reasoning portion is correct.

I voted up this Answer because it makes two key points.

The first is the explanation about how the current result attains, including two relevant documentation citations.

The second is mention of appropriate commands for the query.

@Rotcev It's not clear to me whether you have fully understood my comments above. It matters, here.

I submitted a bug report for this yesterday.

[edit. I had also included C_R's example below.]

You can also get by here with,

   assuming positive

which is shorter still.

There are some others.

Download radical_simp_01.mw

But perhaps it's also mathematically true when a,k,t,m are real and m>0?

Your attachment was last saved using Maple 18.0.

When I run your attachment using Maple 18.02, it runs without error and produces a plot. CR-C_ac.mw

The inability to just use combine here is because the result automatically simplifies with the 2^(1/4) pulled out in front.

Download autosimp01.mw

You can't have the expression in the form you want, unless it is in a special inert representation.

That special inert representation cannot be directly manipulated like the actual mathematical expression -- it can display as you'd like, but it then requires an extra action to turn it back into a programmatically usable form.

Do you need a way to programmatically construct the special inert call?

What exactly are these common ranges that you want to use as a common view, after calling your procedure multiple times?