Outside of silly typos, what is hard-coded in Maple is not always true statements, but most often conditionally-true statements. Like most mathematics, there are very very few universally quantified statements that are true. However, in any given sub-discipline, where quantification is properly guarded, lots of things are true (and Maple knows many such). The issue remains that some of the conditions associated with the application of some (externally proven) theorems are very hard to check. And that assumes that both the developer writing the code knew that there were side-conditions, and that the side-conditions appeared in whatever textbook or paper was used. This is frequently false. In other words, there are tons of theorems in textbooks that are stated incorrectly. Most of the time, this is a partial sin -- if you read the textbook extremely carefully, you'll notice some blanket assumptions at the start of the book (or chapter or section) that are supposed to always be used. These are usually read and swiftly forgotten, because in the book's examples and exercises, the theorem is (obviously!) not applied in those cases. But in a system like Maple, theorems are applied outside of their strict domain of validity, at least as far as published proofs go. And sometimes that's ok, because the theorem generalizes, but all too often it is just plain wrong. And then you get into the realm of deep design bugs. Note: this is NOT a Maple issue. Every single computer algebra system has essentially the "same" bugs when it comes to problems in analysis (the area I know best). Actually, I am planning to teach a complete graduate courses next fall on exactly this problem: how to do computational analysis with formulas "correctly". It is a tough problem, with lots of open questions.

Outside of silly typos, what is hard-coded in Maple is not always true statements, but most often conditionally-true statements. Like most mathematics, there are very very few universally quantified statements that are true. However, in any given sub-discipline, where quantification is properly guarded, lots of things are true (and Maple knows many such). The issue remains that some of the conditions associated with the application of some (externally proven) theorems are very hard to check. And that assumes that both the developer writing the code knew that there were side-conditions, and that the side-conditions appeared in whatever textbook or paper was used. This is frequently false. In other words, there are tons of theorems in textbooks that are stated incorrectly. Most of the time, this is a partial sin -- if you read the textbook extremely carefully, you'll notice some blanket assumptions at the start of the book (or chapter or section) that are supposed to always be used. These are usually read and swiftly forgotten, because in the book's examples and exercises, the theorem is (obviously!) not applied in those cases. But in a system like Maple, theorems are applied outside of their strict domain of validity, at least as far as published proofs go. And sometimes that's ok, because the theorem generalizes, but all too often it is just plain wrong. And then you get into the realm of deep design bugs. Note: this is NOT a Maple issue. Every single computer algebra system has essentially the "same" bugs when it comes to problems in analysis (the area I know best). Actually, I am planning to teach a complete graduate courses next fall on exactly this problem: how to do computational analysis with formulas "correctly". It is a tough problem, with lots of open questions.

Hi Paul! We have unfortunately not crossed paths in much too long. "successful as a presentation mechanism" can be interpreted in two ways: it can do the job, and people are using it (widely) to do so. I fully agree that for all but the rarest of equation, MathML is successful. Whether there is enough "up take" of MathML for it to be considered successful, that is another question. By some measures, it certainly is, else Design Science would not be as successful as it is. But by other measures, I am still unconvinced. For example, let us take math-intensive web sites: all 3 of PlanetMath, MathWorld and Wikipedia use images with LaTeX in the "alt string" attribute. Maplesoft's own web site (when you look at html versions of worksheets) use images with "alt string" set to Maple commands. There are exceptions: one of my favourite super-geek blogs is the n-category cafe, which uses MathML to display its equations. But if you dig just a bit, you'll not that they actually use iTex as the way to enter these equations (but they do link to MathPlayer for those poor folks viewing the web through IE lens). The hype I was referring to in my original post was mostly that from Maplesoft and Wolfram Research when they released MathML-aware products, and the total silence on the issue thereafter. If you look at the web page that was advertized as the "main" web page for Maple+MathML, you'll note that it still refers to Maple 9.5! [A little digging finds a newer page, but that is still Maple 10]. Same goes for Wolfram Research. There was much hoopla about MathML support in 2001, and then nothing. The w3c's pages on MathML show very little (recent) activity on MathML. MathML is not technically doomed, but it does seem to have very little marketing wind left in its sails, just a steady breeze, just strong enough for nimble companies to catch.

link to paper. Officially,you should get it from the ACM. @inproceedings{carette04understanding, author = {Jacques Carette}, title = {Understanding expression simplification}, booktitle = {ISSAC '04: Proceedings of the 2004 international symposium on Symbolic and algebraic computation}, year = {2004}, isbn = {1-58113-827-X}, pages = {72--79}, location = {Santander, Spain}, doi = {http://doi.acm.org/10.1145/1005285.1005298}, publisher = {ACM Press}, address = {New York, NY, USA}, }

Someone else will hopefully answer your question about the Matlab tool for Maple, as I really don't know! That simplification paper was one of my first, and its write-up is overly complex, though the ideas were (and are) sound. The basic idea is simple: MDL, inspired by Kolmogorov complexity, is the "right" way to measure complexity. So, given a base theory, the 'complexity' of any object is the minimum length of a 2-part code consisting of (program, data) where 'program' is encoded using your base theory, and 'data' is encoded using 'program'. Note that 'program' could be declarative, it does not need to be procedural. The basic examples in the paper should make this reasonable. Consider the Chebyshev T polynomials, and consider a base theory BT where you only have polynomials defined. Then there really has to be an n where it is better to first *define* the concept of "Chebyshev T polynomials" as part of your extended theory, and then say that your object is ChebyshevT(n,x) rather than list out an O(n^2) long object. The same thing happens with integer powers. In number theory journals, no one ever prints out a Mersenne prime (waste of paper), just (2^(2^n))-1 for the appropriate n. They are using a base-theory extension where powering (as a term in a term algebra) is added, instead of just the theory of integers. There are also negative results of the same kind: given a theory of integers, TI, the term algebra theory (TI,+) is no more expressive than TI -- in other words, you cannot get an compression/simplification that way. Hopes this helps!

You are now the proud owner of both, which can be used concurrently. I have Maple 8, 9, 9.5, 10 installed, and soon 11 will join that list. Actually, I should probably re-install my copy of Maple 6 too, but I am not sure if I would be able to! Old versions are really useful for cross-checking things when current versions exhibit strange behaviour. Or to congratulate the developers on their great job at improving things, depending on your mood and latest maple-discovery!

Post (at least) the .mw so that we can experiment with it. Or make many of us happy and post just the input lines (using the <code> tags) in a mapleprimes post, so that we can cut-and-paste it directly into our Maple environment of choice.

I believe that if you change your first line to EQ1 := x1(t) = piecewise(x(t)>1, -0.1*sqrt(x2(t)*x3(t)), 0); in other words giving a value of 0 rather than undefined in 'other' cases, dsolve will be much much happier.

this post is the oldest mention of Maple that I can find on sci.math.symbolic. Maple 4.2 for the Amiga! It's great to read those old articles. Maple used to be able to run in 8Megs of memory. Actually, it used to run on a 1Meg Mac too, but that was fairly painful.

This looked like a great post, until I realized that all the inline Maple was gone... What happened?

Does this still work in (all versions of) Maple 11? And does the Maple 11 find Maple 10 installs and copy over preferences? Otherwise, that is a barried to upgrading, at least for someone with a lot of changes to their init file(s).

This code looked interesting, but I cannot see any attachments on the original post -- what happened to it?

This intro by Tom 4 is great stuff, and it would be wonderful if it got another go around. A lot of MaplePrimes users are really new, and probably never looked at some of these early posts. And it might remind Tom that he said 'great prizes' for primes bloggers... Looking at his own posts, Tom 4 has indeed been quite good about his promise of "slogan-free" zone.

The advice above is likely to really confuse Standard users who use the default entry. Especially since one can actually use an e in Standard and have it mean exp(1), there are various ways to get pi (some meaning the Greek symbol, another the constant, yet they are different, more confusion lurks there). Saying that int and Int are different is only semi-helpful, perhaps a link to an online version of the help pages would have clarified this further? And what about a more exhaustive list of such Maple-isms?

The above advice is sound, for someone using either the TTY version, the Classic interface, or even 1D input in Standard, but not for the 'default' Standard interface. That and didn't it occur to anyone while writing this page that those error messages were right out of 80s CS, and maybe they could be modernized some, before they were cast in stone in this forum?