Hopefully you will be successful, and others will be encouraged to do the same. This can be sped up even more, by rewriting it in C (and using external call to get to it). But then again, this routine probably already exists in GMP?

And, as far as I know, how it is still done internally at Maplesoft. Some tools really missing in the setup described by acer are: 1) proper literate programming 2) integrated help file generation 3) integrated unit tests

Having 'my inbox' in bold where there is new mail, and perhaps displaying it in red instead of blue, would help.

As far as I know, it was known, but not considered an important enough problem to hold up the release. If only there was a way for Maple users to have more input on the relative priority of certain bugs...

Myself, whenever I have code that is more than 3-5 lines long, I always switch to a ``programmer's editor'' (like vim or emacs) to do the work. Indenting is then automatic, and various other editing tasks are much simpler. Plus I get syntax-highlighting too, which is now a must for me. I can't stand editing monochrome code anymore, it is just too painful.

Also, the conventions between different forms of the elliptic integrals have changed several times in the last 150 years, with several changes in the last 100. So it is very important to make sure that the definitions that are used in each piece of software (or tables) that you use are clear and consistent. I know for sure that Maple and Mathematica use different conventions here. I believe that even A&S has different conventions depending on the edition [but I could be wrong there].

You are quite right that mixing abstract linear algebra and concrete LA would be extremely tough; a mostly abstract matrix with a known concrete sub-block would be one tough challenge. Note that evalm() provides an ``evaluation environment'' for old-style matrices -- mostly because without it, nothing evaluated! So it too is a bit of a hack. However, what comes to mind would be a command that 'concretizes' something abstract; in some ways, this is like an eval-at (2-argument eval), but specialized for LA. This might work.

My guess is that several Maple developers will read this on Monday morning and they will be embarrassed. They will genuinely wonder why they had not done this earlier. And then one of them will be honest enough to figure out why they have not done this: not because they are not smart enough (they are), not because they don't care (they do), but because 1) their schedules are insane, and 2) they are not encouraged to be that proactive [see schedule - being proactive might encounter problems that need to be fixed, which would take time away from the schedule]. I genuinely expect that every single bug that has appeared in this thread will be fixed in Maple 12. Joe's version of acer's test is also likely to become part of the test suite. I may complain a lot, but I also know the level of professionalism of many of the people who work on the core product. If things have changed so much that these things are not fixed in 12, that would be very scary indeed.

In my experience, most abstract matrices have an abstract size as well (ie m by n or n by n), so that it makes no sense to have an underlying rtable "at the ready". Right now, too much code makes assumptions that rtables have a fixed dimension and size, as well as having its properties being 'concrete'. This is all very good for efficiency. When you break those invariants, you then have to hunt down and back-patch lots of code; worse, because Maple is untyped, there is no easy way to find that code, it has to be found "by hand". So all my instincts tell me that abstract matrices are different enough from the explicit design of concrete matrices that it would be very difficult to make both designs co-exist happily. Not impossible, just hard. Last-name-eval is a glorious hack from the days where even displaying a value was expensive; it should not be used as a solution for anything new!

There may be some interactions with remember tables going on, which would show up with symptoms as you describe them. But that really is a guess.

See ?evalf,Sum where it documents that it uses Levin's u method, which, as it uses 'series acceleration', will find sums for mildly divergent series (documented on Wikipedia).

See ?update,v10 ?updates,v9_5 ?updates,v8 ... ?updates,R5,R51 ?updates,v55 ?updates,v54 .. ?updates,v55 ?updates,v5 ?updates,v43 ?updates,v42 ?updates,v41 ?updates,v4 Jacques

See ?update,v10 ?updates,v9_5 ?updates,v8 ... ?updates,R5,R51 ?updates,v55 ?updates,v54 .. ?updates,v55 ?updates,v5 ?updates,v43 ?updates,v42 ?updates,v41 ?updates,v4 Jacques

I would get in touch with Frederic Chyzak and Alban Quadrat [Google their names, you'll get their homes pages]. Frederic is the author of Ore_algebra, and with Alban they have written a newer package explicitly for control problems. Report back on what you learn, please!

I would get in touch with Frederic Chyzak and Alban Quadrat [Google their names, you'll get their homes pages]. Frederic is the author of Ore_algebra, and with Alban they have written a newer package explicitly for control problems. Report back on what you learn, please!