Most of these are documented, but often in an obscure place: old "What's New". And often one single line in a "What's New". One of the most instructive things to do is to spend the time and read every single "What's Now" in the help system, going back to Maple 4.0 [which long predates Maple V R4]. Those help pages are packed full of hidden gems. Plus they are a fun lesson in history!

Notice how Matrix and Vector are separate constructors from rtable? That is how it is best done -- you create a wrapper around the base data-structure. In fact, it is often best to do exactly that -- you have a named structure, call it Tensor or something like it, which contains an Array with attributes. It is often a bad idea to use 'raw' data-structures are an implementation method for complex mathematical objects with a lot of structure. And that has the advantage that you can more easily define printing routines for it too. Maybe even editing routines, I have not looked too deep into that aspect of Maple 11 (yet).

Do remember that Ore Algebras model (in the differential case) algebras of differential operators, and not algebras of functions. One indirectly models functions as solutions of those operators - like the ideal/variety duality. Another thing to remember is that everything in Ore Algebras has to be pseudo-linear, at least at the level of operators. This is true for both packages. I don't quite understand what you are trying to do with that last declaration of a skew algebra. If you are trying to say that you can shift and differentiate with respect to the same variable (ie model delay-differential equations), then that is not linear, and not supported. I think it would be best if you spelled out the actual problem that you are trying to model here; from that, some people here might be able to help you figure out the best translation into Maple-supported tools.

Do remember that Ore Algebras model (in the differential case) algebras of differential operators, and not algebras of functions. One indirectly models functions as solutions of those operators - like the ideal/variety duality. Another thing to remember is that everything in Ore Algebras has to be pseudo-linear, at least at the level of operators. This is true for both packages. I don't quite understand what you are trying to do with that last declaration of a skew algebra. If you are trying to say that you can shift and differentiate with respect to the same variable (ie model delay-differential equations), then that is not linear, and not supported. I think it would be best if you spelled out the actual problem that you are trying to model here; from that, some people here might be able to help you figure out the best translation into Maple-supported tools.

One way this is solved in Maple itself is to attach attributes to your object which record the extra information (properties) which your objects have. This is how VectorCalculus works (it attaches, amongst other things, the name of the coordinate system to the vector). For example:

> with(VectorCalculus):  X := <1,2,3>;

                        X := e  + 2 e  + 3 e
                              x      y      z

which prints in a nice way. But that's just a trick of the printer, since that's just a plain column vector:

> lprint(X);
Vector[column](3,{(1) = 1, (2) = 2, (3) = 3}, 
    datatype = anything,storage = rectangular,order = Fortran_order, 
    attributes = [coords = cartesian],shape = [])

where you can 'see' the attributes. They are actually attached as attributes:

> attributes(X);

                          coords = cartesian

This design pattern seems to work. Other design patterns have been abject failures [internal state, as in the assume system and unfortunately a few new packages; long weird names with lots of indexing, as in the old stats package], and my personal contribution (and lesser mistake): attaching a table to a data-representation to contain state, as in RESol from the LRETools package. [Personal contribution == I am the author of that sub-optimal design].

Soon Maple's equation editor could rival LaTeX's flexibility (although there is still a lot missing -- commutative diagrams anyone?). The sheer programmability of LaTeX is amazing. And I never actually program it myself - there is always just the right package that already exists, most of them document in the wonderful 'The LaTeX Companion'. There are a few years' worth of work to get close to that. Maple does not even get close, even within 2 if not 3 orders of magnitude, of the quality of typesetting that one gets with LaTeX. Neither for the screen nor for the printer. That is a giant amount of work, and I somehow doubt that Maplesoft really wants to tackle it. BTW, for all that Wolfram Research touts Mathematica's typesetting capabilities, as far as I can tell, Maple and Mathematica are completely equivalent on this front. A much simpler and better route, in my not-at-all-humble opinion, is an excellent export to LaTeX facility. Not like MS Word's absolutely dreadful export-to-HTML facility, which tries to coerce HTML into submission, or even like the current export facility which thinks it knows better than LaTeX how spacing should be done (ha!), but rather an export that respects the fact that LaTeX is the best current technology for typesetting. That is a solution measured in single digit person-months rather than in low 2 digit person-years.

Soon Maple's equation editor could rival LaTeX's flexibility (although there is still a lot missing -- commutative diagrams anyone?). The sheer programmability of LaTeX is amazing. And I never actually program it myself - there is always just the right package that already exists, most of them document in the wonderful 'The LaTeX Companion'. There are a few years' worth of work to get close to that. Maple does not even get close, even within 2 if not 3 orders of magnitude, of the quality of typesetting that one gets with LaTeX. Neither for the screen nor for the printer. That is a giant amount of work, and I somehow doubt that Maplesoft really wants to tackle it. BTW, for all that Wolfram Research touts Mathematica's typesetting capabilities, as far as I can tell, Maple and Mathematica are completely equivalent on this front. A much simpler and better route, in my not-at-all-humble opinion, is an excellent export to LaTeX facility. Not like MS Word's absolutely dreadful export-to-HTML facility, which tries to coerce HTML into submission, or even like the current export facility which thinks it knows better than LaTeX how spacing should be done (ha!), but rather an export that respects the fact that LaTeX is the best current technology for typesetting. That is a solution measured in single digit person-months rather than in low 2 digit person-years.

1. How does one use Maple to script the GUI? 2. Is it possible to create embedded components from Maple?

1. How does one use Maple to script the GUI? 2. Is it possible to create embedded components from Maple?

I meant that as a general guideline rather than as something for this one problem in particular. What you point out seems to be a bug in the CriticalPoints routine in the symbolic case. It is hard to call something a bug in the mixed symbolic-numeric case (since there is no theory to explain what the answer should be), but in either the purely numeric or purely symbolic, there is. So, unless the help page is specific about the symbolic case return just one answer (of possibly many), it's a bug.

I meant that as a general guideline rather than as something for this one problem in particular. What you point out seems to be a bug in the CriticalPoints routine in the symbolic case. It is hard to call something a bug in the mixed symbolic-numeric case (since there is no theory to explain what the answer should be), but in either the purely numeric or purely symbolic, there is. So, unless the help page is specific about the symbolic case return just one answer (of possibly many), it's a bug.

Have you been contacted privately by someone at Maplesoft about this? It is rather disappointing to see no official response to this post of yours.

In the first output, there was a not-equal, which in Maple is <>, thus embedding dreaded < and >. Might that have been it? PS: wonderful use of rifsimp.

In the first output, there was a not-equal, which in Maple is <>, thus embedding dreaded < and >. Might that have been it? PS: wonderful use of rifsimp.

My impression is that integration is considered an "old" topic, where Maple works "well enough", so that further work on it is not urgent or even high-priority. Medium priority or 'soonish', sure. That can translate to a few years though. Basically, what's needed is a new(independent, third-party) review of the capabilities of multiple systems in the area of symbolic integration to be published, to rekindle this topic as something important. There were a lot of good system comparisons published in the mid 90s that fostered serious improvements. Has anyone seen good system comparisons in the last 5 years?