I kept seeing in the help pages for linalg that it is being superseded by LinearAlgebra, so I have tried to work with LinearAlgebra. However, it turns out that LinearAlgebra is very clumsy and annoying for symbolic computations. LinearAlgebra was clearly meant to be a numerical calculation package. Unfortunately, the desiderata for numerical calculations are not the same as for symbolic calculations. The main feature of LinearAlgebra which causes this clumsiness is the requirement that all elements of a Matrix be defined. To do symbolic calculations this means assigning a symbol to use with an index for the undefined elements of the Matrix. The name of this symbol has to be different from that of the Matrix itself, and the indexed symbol is not an array or a table or a Matrix. Already then you have two names for essentially the same thing. ==> First Problem. Now, lets say you do some calculations with these Matrices and end up with expressions that that contain the indexed symbolic names. To assign other values to these indexed symbolic names in the resulting expressions, you have to assign the indexed symbolic names new values and you cannot use matrix operations for that since these indexed symbolic names are not arrays or Matrices or even tables. ==> Second Problem. Now if you want to unassign the symbolic names again or assign new values and have these values show up in the original Matrices, you have to reassign the symbolic names and reassign the values in the original Matrices. (Matrix elements cannot be unassigned.) In other words, do the job twice. ==> Third Problem.

There is a general problem which arises when one uses assume() that can be quite confusing. I seems that once an x~ is passed on by assigning a data structure containing it to another name, it becomes an entity on its own, a sort of vintage x~, with no connection back to the original variable on which the assumptions were made. It has no unique name and no way to access it for manipulation or redefinition. The code x:='x' does not affect these vintage x~'s. Even the function addionally() does not affect these vintage x~'s. Thus one can have a whole set of x~'s of different vintage in one's data structures with no way to tell them apart or manipulate them. This has tied some of my codes in knots before I realized what was happening. It would be so much less frustrating if each new vintage received a unique name that could be referenced by the user.

I have seen a number of forum questions concerning showing students the steps in a problem. There seems to be some confusion about how to do this reliabley and easily. A method I have found useful is seen below:

Maple displays a defined procedure (yours or Maple's)as output when you enter definition or when you execute eval(

As most of you have probably experienced, even Maple 10.4 in standard 2D Maple input has some strange editing behavior. Most of it is of the variety of "What you see is Not what you get". There are two basic kinds of things that can happen: (a)You get strange errors that seem impossible from the code that you can see, such as "missing operation" or "object used as name" or even "non-matching delimiters"; and (2) Your editing action happens much further away or much more extensively than your cursor position or highlighting would indicate. This apparently happens because Maple is creating a parsing structure on the fly behind what you are editing and not visible to you. When some incomprehensible errors happen or Maple seemingly does not want to allow you to edit what you see is wrong, sometimes the only remedy is to retype whole blocks of code (possibly creating other errors in the process requiring the same cure, etc., etc.). Till Maple can supply us with a structural viewer that would allow us to easily find and correct such problems, I want to pass along some tips I have learned in my frustration.