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

@jrive I wasn't trying to sound brusque, sorry. I was unsure b/c Carl had accidentally seen it differently.

FWIW, the words alone don't make it clear which of x1, x2, and (importantly) A are in the set of variables for which you want to solve. Naturally, the code you had, with {x1,x2} passed to solve, helped make that aspect clear.

Clear might be, say,
   solve the equations for x1 and x2 in terms of only DC, T, tau, and A.

Here are two ways. The first uses eq3 and eq4 as side-relations to simplify, and allow a "simplifying" substituion to get rid of ton and toff.

The second merely selects the two results you want -- for just x1 and x2 -- from my earlier suggestion's result.

Download dutycycle_ac.mw

@Carl Love Alas, the effective use of maxsols>1 with fsolve is (currently) restricted to a finite range.

This is crude timing below, showing mostly that it does work.

The subdivide methodology of univariate fsolve is similar to what Calculus1:-Roots(...,numeric) uses, via an internal `minimize/fsolve`. The basic idea is the same as your SubDivide: it's usually much better to split the task at found roots than it is to merely avoid them using the original range.

In general there can be difficulties preventing the undesirable finding of duplicates near the found-roots. Sometimes this can incur extra overhead, I suspect.

Shooting_method_ac.mw

(vote up, btw)

@Carl Love The implicitplot, and the whole example, comes from some Help page. The example, and the methodology, is not authored by me. I merely explained some purpose of part of the code (and made a minor tweak for an inefficiency that bothered me too much to ignore).

@Mikey_W I'm going to back up a bit to even simpler examples.

First, an example the doesn't have this "problem".

f := proc(x) x^3 - x + 2; end proc:

When we attempt,

plot(f(a), a=-3..3)

the first thing that happens is that the arguments to the plot command are evaluated, even before the plot routine receives them to work with. That means that the function call f(a) is evaluated, with its own argument being just a, an unassigned name. The result is a^3 - a + 2, and that expression is what the plot command actually receives.

Now let's use a trickier procedure:

f := proc(x)
  if x > 1 then
    x^2 + 1;
  else
    x^3 - x + 2;
  end if;
end proc:

Now the following attempt produces an error.

plot(f(a), a=-3..3);

Error, (in f) cannot determine if this expression is true or false: 1 < a

That happened because this up front evaluation itself failed,

f(a);

Error, (in f) cannot determine if this expression is true or false: 1 < a

This up-front problem with passing such a problematic argument as f(a) to some command is sometimes referred to by the (old, somewhat amusing) term "premature evaluation".

There are several ways to avoid the problem.

One useful way is to utilize a so-called operator form calling sequence of the plot command. Eg,

plot(f, -3..3)

Another way is to delay the up-front evaluation of plot's first argument, by quoting it with single right-ticks (a.k.a. unevaluation quotes):

plot('f(a)', a=-3..3)

I'm not such a fan of that way, because uneval quotes are ephemeral, and you can't always pass around and more generally manipulate such a quoted thing easily -- because any inadvertant evaluation will strip off a layer of such quotes, possibly throwing the error. And people find Maple's quotes confusing. And trickier situations involving layered/nested pairs of such quotes look even more confusing. 

A third way is to set up procedure f itself so that it can handle the case that its own argument is not numeric (ie. when the inequality cannot be tested against an unassigned symbolic name).

f := proc(x)
  if not type(x,numeric) then
    return 'f'(x);
  end if;
  if x > 1 then
    x^2 + 1;
  else
    x^3 - x + 2;
  end if;
end proc:

And now the following call to f returns itself unevaluated,

f(a);

               f(a)

That expression f(a) is now safe to pass around. Any evaluation of it (as it is, literally) will return merely itself. So the following attempt now succeeds.

plot(f(a), a=-3..3)

The situation in your example is slightly more complicated because there are two levels: the problematic procedure h, and the procedure BC2 which happens to invoke h.

The problem and its various possible fixes all involve what's going on (with up front evaluation) with the first argument being passed to implicitplot. How implicitplot then works to compute its results is secondary, and not directly related to this problem.

ps. Sometimes you might see the bailout in such a procedure written as,
   return 'procname'(x);
instead of (this example),
   return 'f'(x);
That's makes for a more convenient way to program; you can edit the name to which you assign your procedure without having to scour through the procedure's own source in order to change such literal references to itself.

I forgot to mention that there is avoidable duplication of effort in the approach, such as duplicate identical calls to h(a,b) inside the BC2 procedure, etc.

You can make such a call once, then assign to a local name, and then access in multiple places in the formula. It's a simple way to speed this up.

restart;
ode := diff(y(x),x,x) + (y(x))^2*diff(y(x),x) + cos(y(x)) = x:
h:=proc(a,b)
  local F,res;
  Digits := 10;
  F:=dsolve({ode,y(0)=a,D(y)(0)=b},y(x),numeric);
  res:=F(1);
  [rhs(res[2]),rhs(res[3])];
end proc:
BC1 := proc(a,b)
  (1 + a)*b - 3*a
end proc:
BC2 := proc(a,b)
  local res;
  res := h(a,b);
  (1 + res[1])*res[2] - 3*res[1] - res[1]^2 + 0.5
end proc:
plots:-implicitplot([(a,b)->BC1(a,b),(a,b)->BC2(a,b)],
                    -5..1, -11..7, color=[black,red],
                    legend=["BC1(a,b)=0","BC2(a,b)=0"],
                    size=[300,300]);

Title? Caption? Legend? Axis labels? Text positioned beside curves?

You should clarify exactly what you mean by "label".

@chri69a9 Unfortunately your zipped attachment is an empty file.

Not only is there no partial Maple content, it is a file of zero bytes.

Could you try uploading your attachments again, possibly zipping them (.zip file)?

@AHSAN Stop assigning to the names k,Q,Br, etc.

Also, your F is an expression and not an operator or procedure, so it makes no sense when you apply that to arguments.

my_try_ac.mw

I suggest that you really try to understand why and how these mistakes were making it go wrong.