The various Maple library files (.ind/.lib, or .mla) are described as a "persistent store" (see ?updates,Maple6,language about halfway through).  These are rather like a swap file for a virtual memory system.  There is an index to all that is in it, but the pieces are kept on disk as long as possible, to try to maintain the memory footprint of the kernel as small as possible [wish the GUI did the same!].  And what is shown above is the success of this.

In fact, even the index is not loaded into memory either, only those pieces that are needed.  This means that unames and anames actually only know about those names currently loaded, and not those that are in the "persistent store".  This is because a name gets looked up once (and essentially only once) in the store: the first time it is encountered (as 'simpl time' for the cognoscenti).  So if the name doesn't exist in Maple's current state, then neither unames nor anames will report it. In other words, that help page is wrong.

So why do things grow?  Well, when some name is mentionned, if it is assigned, whatever corresponds to it is loaded - which, as a side-effect, may create a lot of new names in Maple's memory (of both assigned and unassigned symbols).  The initial state of Maple contains quite a lot of pre-defined names - and way more so in the GUI.  Actually, you should redo your experiments in the TTY version, as I believe the numbers will be quite different again.  Also, the numbers will be quite different in older versions of Maple too.

The GUI actually pre-loads a number of packages, most notably the context-menu code [otherwise the first context menu, even in Classic, was too slow to come up].  I would guess that Standard preloads other stuff, like the Typesetting package, and so on.  Basically, the namespace of the kernel is much larger in a clean session under any GUI than under TTY.  Note that this is not a trivial issue (because of garbage collection): anytime there is more memory occupied by non-garbage which is fragmented, gc takes longer, which means that all computations that use memory (ie most) are slower.  In other words, for substantial computations, you can measure that running it under the GUI is slower than in TTY version, even if the GUI is otherwise not involved!  [The only way to avoid this would be to have the GUI start a separate kernel, which I don't think is yet the case].

Reading in the whole Maple library, so that one can get accurate statistics from it, is extremely tricky.  I have some code around which I believe does it accurately, and I will try to post it in a blog post later.

As long as Maple remains a closed-source product, that will be so.  Note that this is not necessarily related to Maplesoft being for-profit, as many companies (like Mozilla, Sun and Red Hat) have shown.

That is because if you "evaluate" that function at a very complex expression which is actually 0 but cannot be determined to be equal to 0 (of which there are many), then any kind of approximation of the input will not be able to determine if the output should be 0 or 1.

Note that there are notions of left- and right-computability, where the above becomes right-computable (as it is right-continuous).  But piecewise(x<>0, 0, 1) is not computable in any setting, because it is impossible (through finite computations) to know if the input is equal to 0 or not.  This is, admittedly, a weird area of computer science!

If your system of DAEs has index larger than 2, there is essentially no hope of solving it with that method.  In that case, the only package I know that can handle it is Ned Nedialkov's DAETS package.  If your system is of index 1, then Maple should be able to get somewhere with it.  Are you able to post a worksheet with a 'test' system?

On Linux, sure - but on Windows, if the user has Administrator priviledges, then breaching security from Maple code is very easy.  There are SO many different ways to accomplish it that the only challenge is to come up with something 'clever' rather than just doing it.  [I will not demonstrate this here, that would be irresponsible].

Now, if maple is running with -z, then it is indeed challenging.  I wonder if, instead of using the kernel to breach security, one can use the GUI itself?  That might be challenging too.  A further challenge might be to use some of the external components to breach security [for example, to get the C compiler to execute some code while it is processing some files via Compile].  I am sure other external-calling components could be coerced as well.

On Linux, sure - but on Windows, if the user has Administrator priviledges, then breaching security from Maple code is very easy.  There are SO many different ways to accomplish it that the only challenge is to come up with something 'clever' rather than just doing it.  [I will not demonstrate this here, that would be irresponsible].

Now, if maple is running with -z, then it is indeed challenging.  I wonder if, instead of using the kernel to breach security, one can use the GUI itself?  That might be challenging too.  A further challenge might be to use some of the external components to breach security [for example, to get the C compiler to execute some code while it is processing some files via Compile].  I am sure other external-calling components could be coerced as well.

Can you give more details of what you did there?

I am fairly sure that they can be made consistent. As to when that will happen, you'd have to ask for the prioritized task list for the Kernel Group to figure that out.  Somehow I would guess that this doesn't rank too high...

Actually, "computable functions" are defined in rather technical terms (using rapidly converging approximation and Turing machines).  This in turn leads to a fascinating theorem: all "computable functions" are continuous!  In other words, if you define a "function" as something that can always be evaluated (at all representable points) to arbitrary precision, then the only ones you can represent are the continuous ones.  Note that the assumptions are fairly strong, but that this is so (i.e. that merely asking for evaluation to arbitrary precision everywhere) is actually a fairly deep theorem.

I can give Joe the highest praise which I can give: he has taught me new things about Maple, right here on Primes.

These are numbers that are known to be exactly on the imaginary axis.  This is one way to get around certain issues of having a +0.0 or -0.0 as "real part" which can get in the way of certain exact computations, especially when branch cuts are concerned.  Making some numbers be "purely imaginary" makes more identities hold.

The first rule should really read  x if x is already of type complex, x is not of type extended_numeric and y is not included in the calling sequence.

I guess the authors had 'strictly complex' in mind when writing the first rule, but that is not quite what they wrote down.

My attempts to crack this have not worked, but perhaps some of my ideas might be useful to someone else.

My favourite tactic is to transform such problems into DE problems, so

K := (81/539)*42^(1/2)*hypergeom([-1/2, 3/8, 169/88], [81/88, 19/8], -x/6):
de := collect(numer((lhs-rhs)(op([1,1],PDEtools[dpolyform](y(x)=K,no_Fn)))),diff,factor);

-507*y(x)+(3334*x+18468)*diff(y(x),x)+32*x*(211*x+1134)*diff(diff(y(x),x),x)+1408*x^2*(6+x)*diff(diff(diff(y(x),x),x),x)

3rd order, as expected (but the stupid display of the <maple> tag is annoying here). The coefficients are not too nasty, and nicely the sqrt(42) has magically disappeared. Taking a look at the solution:

ans := rhs(dsolve(de));

_C1/x^(11/8)*(-1+x)+_C2*Int((6+x)^(1/2)*(-81+25*x)*x^(3/8)/(-1+x)^2,x)*(-1+x)/x^(11/8)+_C3*Int(Int(1/x^(81/88)*(-1+x)/(-81+25*x)^2/(6+x)^(3/2),x)*(6+x)^(1/2)*(-81+25*x)*x^(3/8)/(-1+x)^2,x)*(-1+x)/x^(11/8)

[Again, the output in Classic is much nicer than here]  Where does this come from? Well, the DE, as an operator, factors:

> DEtools[DFactor](DEtools[de2diffop](de,y(x),[Dx,x]),[Dx,x]);

                                      2
          2         3       48 (2875 x  + 5911 x - 27378) x
  [(8448 x  + 1408 x ) Dx + -------------------------------,
                                      -81 + 25 x

                             2       3
               -1863 x + 82 x  + 25 x  + 972          -11 + 3 x
        Dx + ---------------------------------, Dx + ------------]
             2 x (-1 + x) (6 + x) (-81 + 25 x)       8 x (-1 + x)

Trying to figure out the values of the constants _C1, _C2 and _C3 turns out to be very hard since all 3 terms are singular at 0, so one would have to find out how to 'match' those singularities, which I have not been able to do. However, it might be useful to know that the problem is "reduced" to one involving algebraic integrals.

I have not tried to use any of the contiguity relations or quadratic transformations formulas for the 3F2 to see if somehow that can cause some of the arguments to 'collapse' and thereby simplify the problem. It's too bad that Maple does not have a 'transformations' package with these formulas as transformations one can apply.

Unfortunately, op and subsop are not completely symmetric. They are 2 totally different pieces of code, and not all of op's features are supported by subsop. I do not know of a 'good' reason for that, just history.

lprint(latex(expression)) ?  That should give you a string which should be interpreted as proper LaTeX.