@Ritti Just ask Maple again:

is(abs(cosh(x)) <= exp(x^2/2)) assuming x::real;
      true

@zhuxian This is also easy with basic Maple commands. Suppose that S is the expression that contains the constants and _C7 is the only one that shouldn't be set to 0. Then do

eval(S, (indets(S, suffixed(_C)) minus {_C7})=~ 0);

When you enter a Question, isn't there a box labelled Tags immediately below the box where you enter the text of the Question?

I reposted your actual math/Maple question as an official Question.

I used my moderator privileges to turn your question into an official Question (which a moderator can do even without tags). Do you see a box +Add Tags  under the word Posted on the left side of the header, to the lower right of your avatar? Try clicking on that.

@Rohith The new example can be handled with a relatively small change to the filter:

value(
   indets(
      InertForm:-Parse("a+(c/d)*log(1+b)+sin(a-b)+a^c"), #string!
      #selects operators with exactly two operands, both of which are names,
      #negated names, integers, or floats:
      And(specfunc({name, (-1) &* name, numeric}, {`%+`, `%*`, `%/`, `%^`}), 2 &under nops) 
   )                                            
);

So, the only changes that I made were adding (-1) &* name to the allowed operands and `%^` to the allowed operators. So, the items selected by this new filter are necessarily a superset of those selected by the previous one since both the operand set and the operator set have been enlarged.

Regarding your terminology: You should say that you're extracting "operators acting on exactly two atomic operands". What you mean will then be much clearer (even though this doesn't conform precisely with the technical definition of atomic used by Maple), because operand alone can apply to subexpressions of any complexity. For example, in a + b/c the `+` has exactly two operands: a and b/c.

@Preben Alsholm If an operator is restricted to having exactly two operands, then sometimes lhs and rhs are used to refer to those operands, even when the operator is not =, <, <=, <>. This is the sense by which the OP is using the terms "lhs" and "rhs"

@waseem Do not repeat the same inane question over and over again. It makes me very angry. Are you less than 10 years old? Next time, I'll just delete it. Be patient: It's not like I get paid to answer questions on MaplePrimes. It is just my hobby. As you can see, I've been working on the problem, but I got stuck. That's in addition to the numerous other MaplePrimes problems that I'm working on.

I'd suggest that if you're asking for help from someone whom you're not paying, that you limit any prodding to at most once per week, and that you learn to do it in a polite respectful way.

I am trying to solve the system with Maple's built-in numeric BVP solver (which is using a nonlinear FEM with dynamic mesh size anyway). The system solves very easily, but the values that I am getting do not agree with the paper at all, not even to one significant digit! I feel that I must have entered something wrong, like a minus sign perhaps. But I have gone over what I typed "with a fine-tooth comb" at least 10 times, comparing my worksheet with the paper character by character, using the 3 places in the paper where the ODEs are given and the two where the BCs are given.

So, I'd like some assistance to find the mistake. Or, at least I'd like someone to tell me that I've entered the system and parameter values exactly as they're given in the paper.
 

Download nanofluidBVP.mw

I have no attachment to the name Type. Indeed, I don't like that it's capitalized, but type was already taken (it being itself a type as well as a built-in procedure). I struggled to come up with a good name. I considered `` (the empty symbol).

Aha, how about eval?

@vv You begin your Answer with a discussion of whether it is interesting. To me, it is interesting if there's any hope of generalization and automation. The domain of generalization would be systems of linear equations that include floor, ceil, and frac. So, do you see any hope for it? I'm not asking you to write the algorithm, just whether you've gotten a sense that it's possible.

@ It's okay: Now that you have given your reasons, it does seem that you have excercised "due diligence" (appropriate to your education level) before concluding that Maple was wrong. And, yes, it was clear to me that you did not intend that to be a strict mathematical proof. And I wasn't criticizing it! I did say that it "does provide some evidence...", not that it doesn't provide evidence.

It turns out that all three expressions are valid solution branches. (I'll try to define that in another post.) And the pair given by Maple is a complete solution set^[1] (meaning that given any numeric (real or complex) value of k, the set's evaluation at that value will be the set of all values of x that satisfy the equation for that k). Nonetheless, given any pair of these three expressions, there are some values of k for which the two aren't equal. (The branches are cut in different places.) That is what is is tellling you. 

So, now I am concerned about your instructor: Why do they say that the solution is wrong? Someone who claims that a parameterized solution (k is the parameter in this case) is wrong should be able to provide a witness, that is, a specific numeric value of k for which the solution is wrong. Please ask them why they think it's wrong, saying that I asked you to ask. I'm willing to consider any argument, even "the format that Maple displays the result is ugly."

^[1]As long as we do the sensible thing about the k=0 divide-by-zero case, that is, return the empty set. And Maple will do this part also if you include the parametric option to solve.

What makes you say that the solutions given by Maple are wrong? As a math educator, I am just curious about your reasoning on that.

What you have labeled "Proof" does give some evidence that your proposed solution is a correct solution. But you don't show any evidence that Maple's proposed solutions are not also correct. You may substitute them into the original equation just as you did with your proposed solution. Try it.

It is true that Maple often arranges expressions in ways that are distasteful to a human reader. This seems especially common with combinations of square roots and minus signs. That alone doesn't make them wrong.

Thank you for the very useful procedure. Vote up. However, it can be massively simplified to

# Type for a variable expression, e.g. x=5.
TypeTools:-AddType('varexpr', 'And'('name','Non'('constant'))='algebraic'):

# Type for a function expression, e.g. f(x)=x^2.
TypeTools:-AddType('funcexpr', 'function'('And'('name','Non'('constant')))='algebraic'):

# Identity type (not 'identical'). Ought to be built-in!
# It saves a lot of redundancy in procedure headers!
TypeTools:-AddType('Type', type): 

# Procedure to assign variable and function expressions.
my_assign:= proc(u::{Type,list,rtable,set}({varexpr, funcexpr}), $)
   if u::'indexable' then thisproc~(u); return
   else assign(`if`(u::'varexpr', u, op(0,lhs(u))= unapply((rhs,op@lhs)(u))))
   fi
end proc: 

I believe that this is functionally equivalent to yours^[1]. Certainly, all the examples run identically. One problem I see with the lengthy code is that it makes it seem as if Maple coding is more difficult than it actually is.

Please let me know if you have any questions about how such simplification is achieved, or why any of the numerous parts that I removed were redundant.

^[1]Except that yours didn't allow mixed containers (containers of both varexpr and funcexpr) whereas mine does, because I thought that that was just an oversight on your part. Not sure. 

@Carl Love I just realized that it was incorrect of me to attribute the original algorithm to Kitonum. After rereading the whole thread, I see that Kitonum actually was just making a correction to the OP's code. So, I apologize for that.

@Carl Love 

This boggles me: If I just declare a to be a constant via the official, documented method for declaring constants (see ?constant),

constants:= constants, a;

then, as far as int is concerned, how is a any different from any other official constant, say, gamma? Yet

int(exp(a*exp(I*x)), x= -Pi..Pi) still returns 0, while
int(exp(gamma*exp(I*x)), x= -Pi..Pi) returns 2*Pi.

Somewhere there is knowledge stored about gamma. For example, Maple knows (at the symbolic level?) that it's positive:

signum(gamma) returns 1, whereas signum(a) returns unevaluated. So, where is that knowledge stored?