Discussion of the merits of implicit multiplication is useful, and the issues of cut & paste of 2Dmath is important. I'd just like to add that the examples that I gave go wrong even when typed in by hand and not pasted. And I suppose that the mod example is another Typesetting issue altogether, and also occurs when typed in by hand. I have a feeling that yet more distinct problematic issues could be found, using the wealth of examples from the help-pages. In other words, the general parsing problems are likely wider than just implicit multiplication. The detail from your Knuth conversation is interesting. I wonder how to disambiguate typeset ouptut without embedding more context into it. I am not anything like an expert in this area. What comes to mind most, though, is the recollection that MathML has both presentation and content forms. The full details of the implementation of 2dmath (input and output!) would be a fascinating read. acer

That doesn't sound so useful, if you cannot type it in successfully by hand. Try typing it in by hand, but in a Worksheet instead of a Document, and in 1D Maple Notation instead of 2D Math Notation. You can open a Worksheet from the File -> New menubar list. You can toggle between 1D and 2D entry modes in a Worksheet either with the F5 key (Windows, Linux) or with a drop-down in one of the top toolbars. If you find that 1D Maple Notation works well for your programming purposes of typing in Maple code, then you could also consider setting the defaults to be in that mode. See the Tools -> Options menu, and look for the Display -> "Input display" and the Interface -> "Default format for new worksheets" tabs. acer

That doesn't sound so useful, if you cannot type it in successfully by hand. Try typing it in by hand, but in a Worksheet instead of a Document, and in 1D Maple Notation instead of 2D Math Notation. You can open a Worksheet from the File -> New menubar list. You can toggle between 1D and 2D entry modes in a Worksheet either with the F5 key (Windows, Linux) or with a drop-down in one of the top toolbars. If you find that 1D Maple Notation works well for your programming purposes of typing in Maple code, then you could also consider setting the defaults to be in that mode. See the Tools -> Options menu, and look for the Display -> "Input display" and the Interface -> "Default format for new worksheets" tabs. acer

Typeset Notation is also known as... interface(prettyprint=2); acer

Typeset Notation is also known as... interface(prettyprint=2); acer

To enable labels in output, for labelled display of common subexpressions, try the following: Go to Tools -> Options -> Display from the top menubar. Change the second item, which is the "Output display" drop-down box, to either "Typeset Notation" or "Character Notation". The help-page ?interface does mention those two as the only output formats to support the common subexpression labels, It doesn't mention how to enable them in the Standard GUI. It's not clear to me that context-sensitive menus will have the same functionality when right-clicking on mouse-selected output in Typeset Notation. acer

To enable labels in output, for labelled display of common subexpressions, try the following: Go to Tools -> Options -> Display from the top menubar. Change the second item, which is the "Output display" drop-down box, to either "Typeset Notation" or "Character Notation". The help-page ?interface does mention those two as the only output formats to support the common subexpression labels, It doesn't mention how to enable them in the Standard GUI. It's not clear to me that context-sensitive menus will have the same functionality when right-clicking on mouse-selected output in Typeset Notation. acer

You could also do this, int(5*sec(2*x)^2, x); convert(%,tan); Note however that application of convert could turn all instances of trig functions in an expression into tan. You might not prefer the result of convert( sin(x), tan ) . acer

You could also do this, int(5*sec(2*x)^2, x); convert(%,tan); Note however that application of convert could turn all instances of trig functions in an expression into tan. You might not prefer the result of convert( sin(x), tan ) . acer

Thanks for mentioning one of the goals explicitly. It is true, in general my way would likely entail some system of symbols, chained in meaning, which would quickly become too burdensome as the examples got more involved. I do think that part of the ability to do abstract linear algebra well in Maple would also allow for the sort of symbolic manipulations of elements that you are trying to describe. Some people would want abstract linear algebra to allow for such element manipulation. Some would want to be able to act on whole subblocks, symbolically. Some would want to be able to specify dimensions of their Matrices and Vectors so as to enable size validation during arithmetic. And some would want to be able to describe one of those objects and leave the dimension unspecified. It'd be hard to please everyone. This next looks dangerous, as another attempt for your example. I keep expecting Maple to "go off forever" as it tries to access an element with a recursive definition. It also prints A not so prettily, when first defined. A_LA:=Matrix(3,3,(i,j)->''A_LA''[i,j]); B_LA := Matrix(3, 3, symbol = 'b'): C_LA := A_LA.B_LA: A[1..2,1..2]:=Matrix([[c, r], [p, q]]): 'C_LA' = C_LA; I also wonder whether indexing functions might be used in some devious way. I only got this far, `index/my_indexing_function` := proc( idx :: list(posint ), M :: Matrix, val :: list ) try a[op(idx)]; catch: 'a'[op(idx)]; end try; end proc: A_LA := Matrix(3,3,shape=my_indexing_function); B_LA := Matrix(3, 3, symbol = 'b'): a := Matrix([[c, r], [p, q]]): C_LA := A_LA.B_LA; C_LA; # whoops Perhaps someone else can think of a clever workaround. acer

This gets the result, A_LA := Matrix(3, 3, symbol = 'aa'): B_LA := Matrix(3, 3, symbol = 'b'): C_LA := A_LA.B_LA: aa := Matrix(3, 3, symbol = 'a'): aa[1..2,1..2]:=Matrix([[c, r], [p, q]]): 'C_LA' = C_LA; Sure, it is one more line. But it still looks nicer than the mess with evalm and copyinto. acer

I might also add this. The call to with(LinearAlgebra) is not needed, for this task, which is somewhat nice. Also, if you really wanted A_LA to no longer have its entries be changed whenever a[i,j] were changed, then you could do either of these at the end, A_LA := map(eval,A_LA); or, even more clear to me, A_LA := Matrix(A_LA); acer

Why did you bother with this next statement, when all you had to do was define a before querying A_LA? A_LA[1..2,1..2] := Matrix(2,2,[[c,r],[p,q]]); The following, without the above, looks easier to me than what you did to get a similar effect using linalg. There's no evalm call needed to do the multiplication, no mysterious copyinto call, both of which are quite confusing to the new user. with(LinearAlgebra): A_LA := Matrix(2,2,symbol=a); B_LA := Matrix(2,2,symbol=b); C_LA := A_LA.B_LA; a := Matrix([[c,r],[p,q]]); 'A_LA' = A_LA; 'C_LA' = C_LA; acer

An important aspect of abstract linear algebra (perhaps *the* point of it, really) is that one can query and obtain results without all the entry-wise arithmetic necessarily being done. So in a basic way, using new-style Matrices with the 'symbol' option (or some equivalent, as you had it) to attempt to "fake" non-computational abstract linear algebra is not going to get nearly what one would want in general. As a very simple example, the transpose of the transpose of a matrix should be recognizable as the matrix itself, with no computation or manipulation of the elements being performed. LinearAlgebra is not going to be able to give the user this sort of power. If it can only mimic the abstract linear algebra work desired, through exact but full explicit computations involving the elements, then it'll unnecessarily scale horribly. Consider what evalm() is able to do, buggy as it might be. O, last-name-eval. And so on. acer

The matrix exponential command is there directly, as LinearAlgebra[MatrixExponential] , so there should be no need to call LinearAlgebra[MatrixFunction] . But something is not quite right. It is super fast for pure floats, but can be slow for exact rationals when the dimension is >=3 . It appears slower by default, in that exact case, than it was in Maple 10. I suspect some simplification or normalization may be taking place within LinearAlgebra[MatrixExponential] , and which might be difficult to turn off. acer