It this move also the reason the <maple> tag, which used to work fine before the site upgrade, is now broken?

Long ago, that was the case because Maple on startup created the first 100 integers in consecutive memory as pre-defined objects.  But now that Maple has immediate integers (since Maple 6), that is not done anymore.  So I am not sure what exactly is true anymore of sets with only small integers in them.  Some testing would be needed to figure it out.

Of course immediate integers are pre-sorted.  But if you have a larger integer that is not immediate, then it will depend on what virtual memory address it has.  Certainly not something to count on!

The change of variable arccos(x) = t gives the simple-looking integral Int(t*sin(t)/(1+cos(t)^4),t=0..Pi/2) which Maple also gets wrong.  Is this the dilog expression that was referred to earlier?

As long as you mean backporting of patches, not backporting of whole packages, that's fine.  One cannot take code which is new in Maple 10's library and "backport" it to an earlier version of Maple.  That would be a violation of (at least) copyright.

If a new package is so appealing that it is tempting to port it to an older release, this is a sign of success (from Maplesoft's point of view), as it means that that package is a real incentive for users to upgrade.  It is not in our best interest (our == the Maple community) to stand in the way of that!

Silly me, my error.

In theory one could write a thin shell above match to implement superalgsubs.  Of course, that would inherit all of match's bugs -- but I think that that would still be the right way to do it.  If match gets used enough, then its bugs might get fixed!

Minor typo: I am sure Joe meant to put alpha^q on the rhs.

Look on the left, under "Create post".  That submits an SCR straight to Maplesoft. 

Look on the left, under "Create post".  That submits an SCR straight to Maplesoft. 

(but I've been wrong on these things before).  The code bases are completely separate, and use completely different ideas.  simplify is a giant pile of heuristics, whereas the Algebraic package is a modern rewrite of evala, done under the supervision of someone who knows the underlying theory rather well (though the author of evala was the creator of some of that theory, truth be told!).

That being said, I am really surprised that Algebraic:-Normal fails here.  That should definitely be reported as a bug.

(but I've been wrong on these things before).  The code bases are completely separate, and use completely different ideas.  simplify is a giant pile of heuristics, whereas the Algebraic package is a modern rewrite of evala, done under the supervision of someone who knows the underlying theory rather well (though the author of evala was the creator of some of that theory, truth be told!).

That being said, I am really surprised that Algebraic:-Normal fails here.  That should definitely be reported as a bug.

If someone dug hard enough in the Maple 11 code, I am sure you'd find a classic Maple anti-pattern: using a raw call to indets to find the "indeterminates" in an expression.  Without using depends in some way, that is bound to fail in exactly the way we see here. What is really sad is that this is clearly a regression!

That said, properly dealing with binders is a difficult problem.  In the theorem proving as well as the semantics of programming languages communities, this is a hot research topic.  There are many competing approaches: de Bruijn indices, Higher-Order Abstract Syntax, Nominal Logic and a locally nameless representation.  These all have their pros-and-cons, but none of them would allow bound variables to escape their scope like Maple routinely does.

are mostly the same.  radnormal is a convenient shell above evala@Normal, and a raw call to evala defaults to mean evala@Normal too.  But you have to look at the code to learn this, it is not in the documentation.

are mostly the same.  radnormal is a convenient shell above evala@Normal, and a raw call to evala defaults to mean evala@Normal too.  But you have to look at the code to learn this, it is not in the documentation.

Something above match could do it:

> match(exp(q*Pi)=exp(n/5*q*Pi),{q},'s');

                                 true

> s;

                               {n = 5}

We are witnessing a fundamental shift in software these days.  In the 80s, it was expected that internal concerns of the developers were going to be visible in the interface (API or GUI) of a piece of software, and that "users" were sophisticated people who could deal with that.  But 20 years later, things have now changed drastically: users see software as tools to get a job done, and expect the software to intrude into their thinking as little as possible. 

This is not to say that this is easy to do.  But take a look at Google maps, for example, and you will see a beautiful such example.  There are many others, of course.