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?

@Scot Gould I submit bug reports on such examples of weakness in simplify. I sometimes forget to mention that in my answers, sorry.

Naturally, simplify attempts many kinds of thing. But it does so circumspectly -- trying to avoid potentially very expensive operations, and recursive calls back into itself, etc. It's a complicated subject.

Those calls like factor(combine(...)) came from an oracle program of mine. I didn't check that they were shortest, and now I know to plug a corner-case hole in which it didn't check. Thanks.

@Gabriel Barcellos If you read the Help page for the select command you will see that it also describes the highly related remove and selectremove commands.

For your B01 example, the select command can produce B011 the sum of your additive terms that contain the mentioned kind of trigh call.

The remove command can produce B011CONST the sum of terms that don't contain such.

And the selectremove command can produce both results, as a sequence of two items.

The second grouping in the Examples Section of that Help page uses has to select from a product of terms. Your example could use hastype (or has, if done right) to select or remove from a sum of terms. The idea is similar: for both a product or a sum the returned object is mostly the same kind of beast as the input.

Note that an empty product comes out as 1, while an empty sum comes out as 0.

Please put your close followup examples on this as Replies here, rather than in a wholly new Question thread.

Also, please either upload a .mw file attachment with your example input, or include it here in valid plaintext Maple notation. (Nobody should have to retype something from a mere image.) Thank you.

You can force that result using,

  simplify(combine(expr, symbolic))

But perhaps you are asking how to establish conditions under which it is true?

@C_R Sorry, I am not sure what you're trying to ask, because your previous example fails due to misspelling.

Download sp01.mw

If it could be the case that your expression is just a single additive term, as opposed to a sum of more than one term, then you'd generally need to guard against that case rather than apply select directly.

Download prcase.mw

There are various workarounds:
- use an if..then..else to test whether expr is of type `+`, and
  if not then apply the hastype against the whole.
- Add some safe dummy (eg. __dum), to make the
  expression into a sum.