This seems to be a weakness of dismantle, which refuses to properly dismantle an rtable. While the inert representation is spectacularly ugly, it does have two advantages: 1) it is correct 2) it is easy to program with These were, in fact, the explicit design goals for the inert form. Previous attempts at reification in Maple tried to be somewhat 'pretty', ie to be somewhat human readable, with the consequence that all of them failed #1 and #2 above.

I think that that book has not been (seriously) updated in several versions of Maple. Also, Appendix A itself is much older than that, so that I am not really surprised that not mention is made of all those useful functions. The written Maple documentation seriously lags behind the product itself. Even in those heavily-marketed areas, the books are sub-optimal, but in those areas which are mostly about the mathematics or programming, the books are something like 4 releases out-of-date.

As well as the SymbolicData project. Our aims and design goals are quite different, so I don't mind starting a new project, but I certainly should coordinate with these people as well [I did not know about CATS, so thanks for the reference].

There is an indirect reference to these in Appendix A of the Advanced Programming Guide. The inert forms pretty much follow the DAGs. One could easily rewrite dismantle in terms of ToInert. I have been meaning to write such an introduction for a while now, but have not found the time. It would be useful for me to have, since I keep having to teach most of my graduate students about this material every year!

The best way to make sure that a project fail is to require too much of version 1.0. LinearAlgebra had rather ambitious, but in the end reasonable goals, that it (mostly) achieved. If the goals had been more ambitious, I am quite certain that the project would have failed. Since then, there has been real updates to LinearAlgebra - but things are perhaps at version 2.1 or 2.2 now [this is not an official numbering, just a communication mechanism for this post]. The question is (to me): what other features of Maple were more important than LinearAlgebra, that it is not at version 4.0 now? To me, it made a lot of sense to put effort into VectorCalculus, and also various Student packages, even at the cost of a slowdown in the development of LinearAlgebra. Other features have already been abundantly panned on this forum. The easiest way to ensure that a particular feature gets implemented in Maple reasonably fast is not to claim that "it just makes sense" to do it, but to show that it makes so much sense that most of the competitors (especially Mathematica and Matlab) already have it. That tends to be quite effective.

For a long time now I have thought that what is really needed is a third-party bug database - not just for Maple, but for all mathematical software. It would be online, and not controlled by any vendor. It could then have features like Roman advocates. If it were used by enough people, then this database would be used by the vendors as well. Regarding some of John's complaints: with my students (as part of my CAS 752 course), we are putting together a fully automated revision of Wester's critique of CA systems, which we will release (expected - late January). We hope to make it quite quantifiable what value a new release offers to experienced users. For certain classes of users, some releases of Maple (and other mathematics software), do not offer substantive improvements, while for other users, the same release can be regarded as a breakthrough. For those users interested in symbolic computation, we hope to make this quantifiable.

Let me play devil's advocate a little bit here. That post essentially says "your design as some serious flaws -- explain yourselves". Why should Maplesoft bother with responding to that? They might even agree with you about those flaws -- but of course could not say so in a public forum, now could they? If Maplesoft was not-for-profit, sure, the developers could be 'honest'. But for-profit companies who worry a lot about image, PR and marketing, you only admit to mistakes when it would be worse PR to do otherwise (think of the Intel Pentium bug years ago, Microsoft Windows security problems, etc). Also, it takes time to respond to such things, time that could otherwise be spent on developing high priority features (ie those features that have the biggest Marketing bang, naturally). The counter to that is that the value of ``expert users'' is often under-estimated. In some sense, this whole website should be proof of the high value of these users. If nothing else, the reduction in support costs is a tangible effect of mapleprimes. Plus, Google provides an added-value component to all the knowledge that is now freely available on the web about Maple. If these expert users get annoyed enough for whatever reason (as has happened in the past), they leave. Or just as bad (?), they stay but keep contradicting the latest ``message'' that Maplesoft is putting out [guilty as charged]. But if you go on over to the Wolfram message boards, you'll see that things are worse over there! In a recent conversation with an avid Mathematica user, he reported that, in his opinion, Mathematica 6 was the worst release ever; basically, lots of things that used to work no longer work. Plus all the new features barely work - they work just enough to get all those wonderful demos going, but too many variations on those demos do not work at all.

The original design goals of LinearAlgebra were to create a package for efficient computational linear algebra - something linalg failed at quite spectacularly. From that goal, it is clear that Matrices of 'base values' is by far the most important case, and so most effort was put to ensure that that worked properly. Later, the issue of easy entry arose, including the idea of entering matrices via blocks. As this was fairly common, it made sense to 'explode' blocks so that a matrix could be filled-in from the entries of those blocks. That explains most of the current design decisions. Only much later did people really start to expect matrices-of-matrices to work. And they do, to a limited extent. But things do break down rather quickly, because that was never really 'designed in'. Should it have been? In my opinion, no, it should not. Getting LinearAlgebra to work as well as it does, for its main task, was already extremely challenging. Getting all these other cases to work too would have made the task impossible. Should those facilities be designed now? Quite possibly. [Although I cannot speak for Maplesoft in any official capacity, I was deeply involved in the early design of LinearAlgebra (but someone else appropriately gets to claim the real credit); so I can speak of my memory of this process. Note quite the official response that John wanted, sorry]

It makes a lot of sense for the 'antisymmetric' property to be defined recursively, instead of being 1-level as it currently is. Hopefully this change request will be 'tracked' and acted upon in some not-too-distant future.

Your experiments seem to show that the "condition number" of this expression is roughly 10^12 (ie you need 12 decimal Digits before you get any kind of stability). That means that if the input constants have less than 12 Digits, the results will vary greatly. I would suggest using evalr on this - while slow, it will certainly show the kind of ill-conditioning being displayed here even more starkly. Then, with a little extra work and some luck, there probably are just a few pieces of the expression which need to be evaluated at higher precision to get good results.

Your experiments seem to show that the "condition number" of this expression is roughly 10^12 (ie you need 12 decimal Digits before you get any kind of stability). That means that if the input constants have less than 12 Digits, the results will vary greatly. I would suggest using evalr on this - while slow, it will certainly show the kind of ill-conditioning being displayed here even more starkly. Then, with a little extra work and some luck, there probably are just a few pieces of the expression which need to be evaluated at higher precision to get good results.

Appears my guess was off - thanks for the correction.

I am guessing that there is a choice of branches involved here, and different implementations have made different choices. Pi/2 is a natural branch-point of arcsin, or seen another (equivalent) way, it is the point at which sin stops being injective as a function starting from 0. It certainly would be nice if these issues were better documented, so that one would at least know the differences between Maple's convention, the A&S convention, the Wikipedia convention, and the MathWorld convention (since all of these are commonly used now).

I must post too much - this one is my 1000th 'comment' on this forum.

The functionality should be there to be helpful to users, not to 'train' users to think in a new, incompatible way! I consider this to be a bug. Some might claim it's a design decision - then it's a design bug. The requirements are clear: help the user. This does not do that - so it's a bug.