The Maple algorithms are expected to be exponential. This is due to expression size blow-up. See the paper Hierarchical representations with signatures for large expression management and Linear Algebra using Maple's LargeExpressions Package for some theory and some ways around this.

I completely agree with you. And if you delve into the source code, you'll see that there are bits and pieces of special case sparse linear algebra hand-coded all over the place. This is a maintenance nightmare, and makes the code base way bigger than it needs to be. All those pieces should be re-coded to go through LinearAlgebra. And then, when that turns out to be a bottleneck, it could be fixed in one place. Right now, improving LinearAlgebra would sadly improve very little of Maple, because of what I say above. Over the long term, that is clearly unsustainable. In other words, Maple will increasingly leave the door open for another system to win the efficiency race. Of course the question of whether there is a big enough share of the market who cares is a completely orthogonal question (and the answer may be that that market is too small to bother with!).

The architecture of plot3d has not changed at all since it was first implemented more than 15 years ago. The renderers have been changed many times, but that's not where the problems are, it is in the ``architecture'' of the communication between the kernel and the GUI (and the fundamental design of the underlying data-structures handled by the library). To be honest, I personally don't know how to fix that without introducing some backwards compatibility problems. Technically speaking, I am quite sure that the developers at Maplesoft, if given a free hand on how to do a better 3D plotter, could do something amazing. But if they need to be backwards-compatible, I don't know if it is even possible. That's probably a big part of why this has not evolved much in the last N years.

Notice this:

> outerproc(['exp(0)']);

                                exp(0)


                                exp(0)

> outerproc(Vector(1,['exp(0)']));

                                exp(0)


                                exp(0)

which is 'as expected', since everything gets evaluated to one level. But in certain circumstances (which I do not remember exactly, sorry), tables get evaluated more deeply than they should. This fixes some problems (and is a hack), and introduces others, as you have noticed.

Since you have not had an answer here, ask tech support. I am fairly sure I have seen such things done, but it is not so obvious how to put all the tools together (unlike what you can do in Python or Perl, where this is trivial).

I meant to comment on your other point: it is my personal experience that a lot of Maple users ``sit'' on their cache of (Maple) bugs that they encounter, rarely reporting them officially. Whenever they encounter someone somewhat linked to Maplesoft (like me), they spill their guts. I got another example of this over the last two days at a workshop I was at. These users incorrectly assume that most of the bugs that they have encountered are known: back when I worked at Maplesoft (and because of the job I had, had a pretty good idea of the known bugs), I almost always learned about new bugs in these user-encounters. It really saddened me that these had not been reported, because we then had had no chance of fixing them!

A bug forum, parallel to the product suggestion part of the site, would be a really interesting idea. If Maplesoft actually did as you say, that could be a tremendous marketing tool: being that open about the bug-fixing process (and feedback) could propel Maplesoft to the head of the ``customer support'' leagues. It could be used to show the trememdous cultural difference between Maplesoft and its rivals -- none of which I think would have the gumption to be that open. They have a rather long history of deep secrecy.

This works:

> p := int(exp(-x)/sqrt(x^2-1),x=1..infinity):
> simplify( student[changevar](t=1/x, p, t) );

                            BesselK(0, 1)

This works:

> p := int(exp(-x)/sqrt(x^2-1),x=1..infinity):
> simplify( student[changevar](t=1/x, p, t) );

                            BesselK(0, 1)

If I could not find this part of this site easily, how will less frequent visitors? Plus, now that I read Tom 4's announcement when that was started -- where are the comments from Maplesoft staff on feature requests?

Someone kindly pointed out to me that I made a typo -- it should have been $ifdef, not #ifdef.

Someone kindly pointed out to me that I made a typo -- it should have been $ifdef, not #ifdef.

It's good to know that my Maple instincts are still pretty good! But there are corners of Maple 10 (and of course 11) that I just don't know. Very sad. Oh well, I still know the hardcore stuff pretty well: int, limit, series, simplify, combine, rsolve. I've tried to keep up with dsolve, but that's quite challenging!

It's good to know that my Maple instincts are still pretty good! But there are corners of Maple 10 (and of course 11) that I just don't know. Very sad. Oh well, I still know the hardcore stuff pretty well: int, limit, series, simplify, combine, rsolve. I've tried to keep up with dsolve, but that's quite challenging!

You'll notice a trend (which has been bemoaned here before): there are many links from new help pages to old ones, but very few from old pages towards new. curry is a new-ish command, unapply is antediluvian -- so no links.