You are unknowingly mixing up types and properties in that you're expecting a type to act like a property. Here's a discussion of both. Although it may seem like properties are much more powerful, you'll definitely want to stick with types in this case for their robustness, definitiveness, and simplicity of programming.

Given any Maple data structure x and any type t, either x definitely has or definitely doesn't have type t---there are never nebulous cases where possesion of the type can't be determined (due to x being symbolic or any other reason)^[*1]. So, if x is not numeric, then it's definitely not of type integer nor type even. Examples of types include numeric, integer, even, odd, algebraic, and complexcons.

Types can be contrasted with properties, which can be nebulous (i.e., subject to 3-valued logic). The commands to check whether x has property p are is(x::p) and coulditbe(x::p), and one of these four cases applies:

1. x definitely has the property;
2. x definitely doesn't have the property;
3. mathematically, there's not enough given information (in the current assumptions) to determine whether x has the property;
4. Maple cannot determine whether x has the property although there's theoretically enough information to make that determination.

The corresponding returns from is or coulditbe are true, false, FAIL, FAIL, respectively, for the four cases. These are the values of Maple's 3-valued logic. (No attempt is made to distinguish cases 3 and 4.) The difference between is and coulditbe is significant when x is symbolic and it corresponds to universal or existential quantification:

• Universal (is): Do all possible values of x under the current assumptions have the property?
• Existential (coulditbe): Does there exist some value of x under the current assumptions that has the property?

An example of a property that isn't also a type is real. Unfortunately, there are several names which can be used as both types and properties, easily leading to the confusion that caused you to ask this Question.

Obviously from the above discussion, working with properties is quite subtle, and I haven't even discussed what precisely is meant by the current assumptions. However, it's far more important that you learn to work with types than with properties, so I won't discuss properties any further in this article.

It happens very often that you want a procedure to do nothing when it's given non-numeric input or other input that it can't or shouldn't handle. Formally speaking, you want the procedure to return unevaluated. In these cases, the procedure's return value can be coded as 'procname'(args). Thus, your even/odd procedure could be

M:= (n::And(algebraic, Or(integer, Not(complexcons))))-> 
   `if`(n::integer, n mod 2, 'procname'(args))
:

Notes:

• In those cases where it'll do the job, `if` is far more efficient and far more robust than piecewise.
• When a::b appears in a context requiring a true/false value, it's essentially equivalent to type(a, b), but more robust because it works even if a = NULL.
• My type declaration for n---And(algebraic, Or(integer, Not(complexcons)))---is intended to exclude (with an error condition) manifestly garbage input such as 6.3 or [x, y, z]; i.e., things that could never be integers even if their symbols, if any, were given numeric values.

[*1] It's possible to define types (and this can very easily happen through sloppy programming) that do not return true, false, or error for some inputs. There is never any good reason to do this, and it can lead to very serious problems, including kernel crashes. (Note that error is not the same as FAIL.)

Please respond to my Answers!

Use plots:-display(a, b, c) because display is in the plots package and always has been.

Your older worksheets probably included the command with(plots), which would've allowed future references in the same session to be display(...) rather than plots:-display(...); however, I prefer to explicitly use package-name prefixes such as plots:- whenever possible.

If you have a solution set or list named, for example, Sol, and it contains equations such as {A = 3.54, B = 4.67}, then you can do assign(Sol).

To go downhill at locally maximal descent (like water would), follow the negative gradient. Here, I've done it with dsolve, but there may be another way. The path will stop at any local minimum or saddle point, of course, which is what happens in this plot.

restart:
f:= (x,y)-> 3*(1-x)^2*exp(-x^2-(y+1)^2) - (2*x-10*x^3-10*y^5)*exp(-x^2-y^2) - 1/3*exp(-(x+1)^2-y^2):
bp:= <0.2, 1.4>: #initial point.
Sol:= dsolve(
   {diff(X(t),t) = -D[1](f)(X(t),Y(t)), diff(Y(t),t) = -D[2](f)(X(t),Y(t)), X(0)=bp[1], Y(0)=bp[2]},
   numeric
):
plots:-display(
   plot3d(f, -3..3, -3..3),
   plots:-odeplot(Sol, [X(t), Y(t), f(X(t),Y(t))], t= 0..1, color= red, thickness= 3),
   orientation= [-40,60,0]
); 

My choice of t=1 as an endpoint for the integration was just a guess, but it's at or near a local minimum, as can be seen by rotating the plot.

The procedure Diffs that you want can be written like this:

Diffs:= proc(e::algebraic)
local t;
     subsindets(
          subsindets(
               diff(subsindets(e, And(name, Not(constant)), n-> n(t)), t),
               'diff'(anyfunc(identical(t)), identical(t)),
               d-> PutDelta(op([1,0], d))
          ),
          anyfunc(identical(t)),
          f-> op(0,f)
     )
end proc:

where PutDelta is as specified by Acer.

As far as your computer cares, there's no meaningful difference between a .txt and a .mpl file. The only purpose of ".mpl" is long-standing tradition (at least 42 years) that plaintext files of computer code have a file "extension" (the part after the dot) that indicates the language that the file is written in. So, there's no conversion; you simply rename the file. Alternatively, Maple would be just as happy to read the .txt file.

Maple has a built-in conditional ternary operator `if`. Note that the backquotes distinguish it from if as used in if-statements. It has smart evaluation rules: Only 1 of the 2nd and 3rd operands gets evaluated, becoming the operator's return value.

`if`(x=3, 1, 0)*x^2

`if`(g(x)=x^2, 1, 0)*f(x)

If you're defining objects, then it's possible to define the meaning of [...] when it's placed to the right of those objects. So, in that case, you could do it exactly the way you asked. DataFrames are examples of objects where the brackets are defined in a way similar to what you suggest. They are essentially matrices that can be indexed by boolean relations.

My code for this uses irem, which computes both an integer quotient and its remainder in one step. It also uses multiple assignment, which allows one to switch two variables without using an intermediate third variable. And, finally, this code works for any integers a and b, regardless of their signs or which is greater.

GCDwithBezout:= proc(a::integer, b::integer)
local q, r0:= a, r1:= b, s0:= 1, s1:= 0; 
     while r1 <> 0 do
         (r0, r1):= (r1, irem(r0, r1, 'q'));
         (s0, s1):= (s1, s0 - q*s1)
     od;
     sign(r0)*[r0, s0, `if`(b=0, 0, iquo(r0-s0*a, b))]
end proc:

Method using strictly the techniques of single-variable calculus:

You need to use function variables, which are expressions such as f(x) that show a dependency between a function and its independent variable(s). You want the derivative with respect to t, which makes t the independent variable. So, you need to replace z with z(t) in your original equation: 

Eq0:= z*t = cos(z + t):  #original equation
Eq1:= subs(z= z(t), Eq0); #function variable adjustment

Now, assuming that you understand the rules of explicit differentiation (most importantly for this problem the product rule), there are only two more steps needed to do implicit differentiation. First, take the derivative with respect to t of both sides of the equation:

Eq2:= diff(Eq1, t); #both sides done with one command!

And then solve for the derivative:

Ans:= solve(Eq2, diff(z(t), t));

If you were solving Eq2 by hand for the derivative, note that the equation is always linear in the derivative and thus easy to solve by Algebra-I methods.

An optional clean-up step would be to re-express the answer with the original z instead of z(t):

subs(z(t)= z, Ans);
 

Much easier method that uses a tiny bit of multi-variable calculus:

Amazingly, all of the above can be combined into two very short steps using a simple idea of multi-variable calculus: If we subtract one side of the original equation from the other, then the resulting expression can itself be considered a function of two independent variables, z and t. There's a remarkable and simple relationship between the derivatives of this new function, F, with respect to its independent variables and the derivative that we want:  dz/dt = - (dF/dt) / (dF/dz). To remember that formula, you can imagine that these are fractions where the dF cancels; then include a minus sign. Now, professors and textbooks may make a distinction between ordinary derivatives and partial derivatives--and they use a fancy curly letter d for the partials--but there's really no practical difference and Maple doesn't care. 

The first short step is to subtract one side from the other:

Eq:= z*t = cos(z+t): #original
F:= (lhs-rhs)(Eq); #left-hand side (lhs) - right-hand side (rhs)

And then apply the derivative relation that I explained:

Ans:= - diff(F,t) / diff(F,z);

That's all that there is to it! If you were doing it by hand, it doesn't even require the product rule or solving an equation for the derivative! Since this method is so much easier and so much less prone to error (when doing by hand), I recommend it to all my single-variable calculus students as a means of checking their work done by the first method, which their formal instructors may require them to use.

Implicit derivatives can usually be expressed in multiple equivalent forms which are totally correct but whose equivalence is not immediately apparent. To show the equivalence, you may need to reduce with respect to the original equation. 

The command is Statistics:-ColumnGraph. If you can't get the appropriate labels on the horizontal axis, let me know. It's fairly easy, but, unfortunately, no example of that appears on the help page.

The problem of the USB sticks is called an Integer Linear Program or ILP for short. It can be solved like this:

Optimization:-LPSolve(
   32*x + 64*y + 128*z, 
   {15*x + 20*y + 30*z <= 200, x >= 0, y >= 0, z >= 0},
   assume= integer, maximize
);
     [832, [x = 0, y = 1, z = 6]]

The 832 is the maximum number of GB.

There are a vast number of ways to do that. Here's one way:

FullSpeed:= 3600:  #whatever number you want
FullTorque:= 700:  #whatever number you want

Current:= (tq, sp)->
   #Put your equation for current here
   tq^2 * sp #I just made that up
:
P:= plot3d(Current, 0..FullTorque, 0..FullSpeed, grid= [11,11]);
interface(rtablesize= 11): #Allowed Matrix size to print.
Current_Matrix:= op([1,3], P);
#The row index varies the torque; the column, the speed.

Except for one small detail, this is a straightforward elementary textbook linear-programming problem. That detail is that the problem states the resource consumption in units per day, whereas we need days per unit. This is the reason for the 1 /~ in the code below.
 

Download LP.mw

It's a mystery to me why FrequencyTable doesn't offer that option. The similar command Statistics:-TallyInto does offer that option. If you need the output of TallyInto formatted similarly to FrequencyTable, let me know.

The matrix or any other structure or structures that can be assigned to a name can be saved by

save M "MyData.map";

where M is the matrix and the quoted string is any filename of your choice. Then, in another worksheet, do

read "MyData.map":  #Use : to suppress lengthy output!

and then the name M will have the same value as it had in the first worksheet. The above uses a plaintext file. If you read it with a regular text editor, it'll look like an elaborate Maple command starting M:=. If you change the file extension from .map to .m, a faster but non-plaintext file format will be used.

If M contains references to other variables which are not being saved in the same batch, then there can be subtle differences between the .m and plaintext formats. These differences are too deep to explain here.