Often, when using an if-statement to make a comparison between exact numbers such as  or , I'd find that Maple couldn't determine if the comparison were true or not. The cure I would then use would be to apply the ?evalf command so that the comparison would be between floating-point numbers.

Not so long ago I asked why the following version of the if-command generated the error shown.

What I learned is that the if-statement can only make comparisons between "numbers" and that  is not a number. It is an "unevaluated function call." Similarly,  is a "symbol" and , the exponential "e," is a function. I then learned that modifying the if-statement to include the is command works. Thus,

Similarly, we would also have

In math mode, typing the numeral 4, followed immediately by a name such as , produces the product . Again in math mode, typing the numeral 4, followed immediately by a parenthesized expression such as  produces the product . If  is defined in Maple as a function, then  evaluates to the number 6. In math mode, if  is followed immediately by the parenthesized expression , the result is 6, not .

Why is this? Why isn't  evaluated to ?

The answer is that  is "parsed, but not evaluated." Since  does not then evaluate to a number, Maple can't apply the default Typesetting rule that treats  as a product, and not as the constant function 4 evaluated at . This default rule can be modified by the command

in which case  reverts to the constant function 4 evaluated at .

The default setting is probably the preferred one, but in this case (arising from the equation of a tangent line), care must be taken to provide some form of explicit multiplication, either with a space, or with the asterisk.

Not long ago I was asked how to replace the product  with  in an expression such as

Table 1 contains three different answers that I was able to provide.

The ?algsubs command was designed for this type replacement. However, it handles only one replacement at a time. Multiple replacements require multiple applications of the command.

Attaching assumptions to variables with the ?assume command has on-going effects because the variable with the assumption is different from the same variable without the assumption. Once the assuming facility became available, I made exclusive use of it because it allows "local" or "in-place" assumptions that are active only for the duration of a given calculation.

However, a recent user question about assumptions on table elements caught my attention. Recall that in Maple, the subscripted variable  is actually an element of a table whose name is . Hence, my interest in the two questions  raised.

Question 1: Can separate assumptions be made on subscripted variables?

Answer 1: Yes. Table 2 gives an example, and shows how to verify that the assumptions are indeed attached.

The last line in Table 2 illustrates the use of the tilde (w) as an element-wise operator to map operations onto members of, for example, a list. This in itself is a useful gem to keep in mind.

These assumptions cannot be selectively removed. The complete table must be cleared of assumptions, as we see in Table 3.

So again, an assumption on a single table member can't be selectively removed. Assumptions on all table members must be removed at the same time. However, Table 4 shows that the assuming facility makes assumptions "in-place."

The following investigation started with an example of directional derivative, computed stepwise, without having to load any supplementary packages. Table 5 summarizes the calculations whose results are at issue.

References to the vector N, supposedly , are in terms of the evaluated derivatives that constitute the gradient. The overbars denote conjugation because Maple's dot product sees only symbols that could, perhaps, be complex. Fortunately, a call to simplify in the Context Menu results in the correct value of the dot product.

So the challenge is implementing these same mathematical steps without having the dot product echo in terms of . The Maple magic is to define the gradient vector with angle brackets, or to use the Matrix palette in text mode. These forms of the calculation are summarized in Tables 6 and 7.

Apparently, the difficulty shown in Table 5 occurs when the Matrix palette is used in math mode. Table 7 shows these same calculations with the Matrix palette used in text mode.