There are Russian mathematicians who work (part-time) for Maplesoft [they get some research grants] who specialize in the numerics of special functions, and have done a great job with Maple's, 2F1 in particular. Hopefully the internal people at Maplesoft can help you out here (it would be inappropriate for me to do so directly, at least without their permission). It theory NIST's Digital Library of Mathematical Functions (DLMF) project should have done this already, but it looks like it has stalled. Also stalled is the Encyclopedia of Special Functions (this last one is all Maple driven, so it is doubly sad that it has stalled). Some old project from Amsterdam has other useful links. There is a book available on this topic. Strangely, the otherwise fantastic MathWorld does not say much on this topic.

Your question is not quite precise enough to propose an answer. The only think I can suggest from your question is to look at ?D.

The maple philosophy has long been that generic answers are sufficient. In fact, that completely correct answer, with all the cases spelled out, is too much for most users. In other words, most users can't handle the truth. To be fair, that has been changing slowly. In 1991-1992, the prevailing philosophy was that the dreaded square root bug could never be eradicated, and yet in 1993 it was mostly gone and Maple [and all other Computer Algebra Systems] survived. Then it was various automatic simplifications that were supposed to be impossible to fix - and in Maple 6,7,8, a lot of them were removed and Maple 10's computational power is just fine. And so it is for fixing various other parts of Maple to output correct answers instead of generic answers. From what I can see, steady progress is being made on this front too, but the pace is not what one would call quick. From my experience with the typical pace of development on these things (I have been using Maple since 1985, and used to be at Maplesoft before I heard the call of academia a few years ago), either there will be a release soon (2008?) where huge progress is made, or most of these problems will have been fixed by slow evolution by roughly 2011. And yes, I am serious about those timescales. Steady pressure from users does make a difference. Actually, pressure from reviewers in trade magazines is even more effective! If you want to get Maplesoft to change something quickly, put it in print in a trade magazine with a high circulation, and where the blogosphere picks it up.

I looked at the online code for this. Whoever did the translation from the older edition of the book introduced a number of mistakes in the code. For example, you can see it clearly in the first few lines: DividesRelation is expecting a set, but it is called with an expression sequence. The other thing to notice is that the code is very old -- this looks like Maple V R4 code to me! In other words, code from about 1994-95. And it is dreadfully inefficient too. Scarily inefficient. And it teaches really bad Maple-coding habits. It would take quite a lot of work to modernize all of this into something reasonable.

charfcn and piecewise are the discrete functions, Dirac (in maple anyways) is a functional which does not really ``plot''.

In the deep dark past, there was a version of Maple for Windows CE that ran on just one machine (since all those CE machines were on weird CPUs at the time). It ``worked'', but that's about as much as can be said for it! Take a good look at Maple, and you will see that it really is many different products in one. One product, the glorified calculator, could potentially be done on a PDA. In fact, many old TI calculators do just that, but with Derive (a darn fine CAS by the way) instead of Maple. But even that has problems as frequently the answer does not fit on the tiny screen. Which leads to all the other uses of Maple, whether it be as a presentation device, exploration medium or some new applications, bottom line is always the same: such uses are very screen real estate heavy. In other words, they need a lot of screen space. So while Maple on a PDA seems like a cool idea indeed, most use cases for it show that there is an impedance mismatch between the product and the media. This is not Maple specific -- many companies are having a really hard time making their web-based products work properly on the small screens of cell-phones and always-on PDAs. Ever wonder why the most successful such device, the RIM Blackberry, has a comparatively huge screen? Now you know. In fact, this need for being able to use all available screen real estate when doing work in Maple is so strong (at least in my uses), that even though I have a giant screen (23 inches diagonal, which I run at 2048x1536, the equivalent of 4 full 1024x768 screens), I still get annoyed by some of the real waste of useful space by the (new and even a little bit the old) GUI. Ah well, I am saving up my money to buy a bigger screen, although what I would really like is too pricey.

For some strange reason, if statements are not allowed in the -> notation. There are two solutions: either use an if expression, or use a procedure. More specifically n -> `if`(n=1, 1, `if`(n=NInts, 1, 2)) and proc(n) if n=0 then 1 elif n=NInts then 1 else 2 end if end proc respectively. Note that better style would be n ->> `if`(member(n,{1,NInts}), 1, 2). Even better (for use in more Maple routines) would be proc(n) if n::integer then if member(n, {1,NInts}) then 1 else 2 end if else 'procname'(args) end if end proc

The command in Maple is LinearAlgebra[MatrixInverse], which returns Matrix([[0, 0, 0, 1/d], [0, 0, 1/c, 0], [1/a, -1/b, -1/c, -1/d], [0, 1/b, 0, 0]]) on your example. In fact, A^(-1) would have worked too. Jacques

Vim comes pre-packaged with Maple syntax highlighting and indentation (as well as syntax highlighting for most languages you can think of, and then more). I know several Maple insiders who use it exclusively for their Maple work.

The previous posts give good advice. Another point to consider is (very large) output: it looks fine on a screen, and you can happily navigate it when you are doing mathematical explorations yourself, but it looks bad in a presentation. This is no fault of Maple's, it is just more difficult to give the audience the right sense of perspective on such output. If all your outputs are small, you have no problem, but if some are huge, you need to make an explicit decision as to how you will (or will not) show it. The advice of using sections and sub-sections carries over to this - they can be used to delimit large output. Also, remember to put an empty prompt at the end of your sections, if you are interactively executing Maple, else Maple will "jump" to the next prompt, which often ruins your presentation flow.