But I like the save command because it produces Maple input as text. Then I can use my "text editor" to edit it in a "terminal window". Hey you kids, get off my lawn!

The way to save objects in Maple is to use the save command. For example:

A := Matrix([[1,1],[0,1]]);
save A, "file1";
B := Matrix([[2,3],[1,4]]);
save A, B, "file2";

This will save the matrix A to file1 and both A and B to file2. Later you can load these files using the read command and the values of A and B will be restored. For example:

read "file1";

The default format for these files is plain text, which is convenient because you can edit them with a text editor, but inefficient for large matrices because it uses 8 bits per digit where 3.3 bits would suffice. For double precision floats it is even worse. You can get some of this space back by using Maple's binary format:

save A, "file3.m";

The save and read commands detect the .m extension and use the binary format. I tested this with a large array of 32-bit integers (integer[4] in Maple) and found that going from text to binary cut the file size in half, and using gzip compression on either file produced a file that was half the size of the binary file.

Thank you for the papers on partial evaluation, I had not seen them before and I found MapleMIX very interesting. Of course, if the user is willing to accept a program as output then then the problem goes away, until they ask for all the possible branches that the program can take. i.e. they will ask "what are all the possible conditions that affect the result ?" and the answer will be huge. It was my impression that the original poster wanted to see that sort of thing. One idea would be to return a program that uses partial evaluation to walk through the tree of all the conditions and compute the final results very efficiently, but I don't think that is a sensible default (although it would certainly be valuable!). I think it would be better to just return the set of assumptions Maple made while computing the generic answer. ie:

Matrix([1,1,0],[0,0,1]]) assuming {a-b <> 0};

Here are my suggestions in no particular order: - Integrate LinBox, or provide something fast for sparse linear algebra over the rationals and the integers mod p. Maple has been weak in this area for a very long time. - Make an applet for the GraphTheory package that allows a user to draw a graph using a tablet or the mouse. Entering graphs manually is a pain. - Write something to solve nonlinear systems with inequalities. For example solve({x*y > 0, x^2+y^2 < 2}) outputs nothing except "warning, solutions may have been lost". - Improve the speed and decrease the memory usage of the standard interface. There is an embarrassing video on sci.math.symbolic of Maple 11 taking 3 minutes and 1 GB of ram to copy 4 pages of output. I hope this is a bug. For what it's worth, the performance of standard interface greatly improved with Maple 11, but you just have to keep hammering away on this until everybody clams up. - Improve the speed of the multithreaded kernel with the goal of making it the default, if not for the next release of Maple then certainly for the release after that. By the time Maple 13 (?) is released a $500 computer will have 4 cores. And for the company itself: - Teach people how to use OpenMaple, or at least provide more real world examples of how you can do things. For example, many people probably do not know how to disassemble and construct Maple objects in external code. When they go to do a project (for example this one) they build on open source system because they think they need access to the Maple kernel and can't get it. I have nothing against open source, but these are missed opportunities to get good projects to benefit Maple. - Start more partnerships to bring more expertise to the project. In particular, find people who have written the best or the fastest software for a fairly general problem and partner with them to integrate that software into Maple. The long term goal is to build a system that can compute anything.

The problem with this idea is that it doesn't scale. For every step involving a symbolic expression you would have to split a computation into subcases, and every algorithm would have to call itself recursively while keeping track of assumptions on parameters to detect contradictions. Nevermind the nightmare of coding this, you would not be able to get through even a small non-trivial example before the exponential blowup brought the system to a halt. If you are genuinely interested in doing these problems, you should look at the RegularChains package. I don't think the functionality is even implemented anywhere else. For what it's worth, this is what I hate about the assume facility in Maple. It promises something that it can not possibly deliver. Worse, it works for some simple cases so people reasonably expect that this functionality is in the system when it's not. For example, I know for a fact that Maple doesn't have cylindrical algebraic decomposition (or an equivalent), so if your assumptions are a set of polynomial inequalities then you could get total garbage. I would like to see a careful account of what sort of functionality is promised to the user compared to what Maple actually has. In theory, "solve" means the system can do anything. I wish more people would find that hard to believe :)

However, it is rather inevitable that it will become bloated: Maplesoft needs to push out new versions for people to upgrade to, and to be able to sell those, 'new' features have to be there to warrant an upgrade, right? True, but you can always trash old buggy code and replace it with new good code. Arguably, that is what the customer is paying for. Maplesoft can keep adding features until functionality outstrips the design, and then design a new module or package from scratch. There are always great opportunities to reduce bloat when you redesign something.

Thank you for your posts on this topic, I've found them insightful.

Unlike C, functions in Maple are first class objects. They are treated like any other piece of data, so it is consistent for Maple to issue a warning for them.

Unlike C, functions in Maple are first class objects. They are treated like any other piece of data, so it is consistent for Maple to issue a warning for them.

I tried it on the release candidate and it works.

Although I can't be completely sure, this looks like an "ordering issue". You should report it as a bug to support@maplesoft.com. What is happening is this: the time required to solve equations can depend heavily on the order of the variables, where the most significant variables are eliminated first. Most parts of Maple use heuristics to pick "good orders", however these can always produce a tie and in that case the result will be partially random. To further complicate things, the heuristics used by the system change over time as different algorithms are added and also in response to bug reports. The message about _EnvAllSolutions indicates that solve was called and that it was unable to find a solution for whatever order it was using. The fact that it can sometimes find a solution suggests that the order is partially random, and the fact that Maple 8 always worked tells us that either someone changed something and broke it or the heuristic was just always lucky in Maple 8. That second possibility is actually not a joke, it happens, and it can be hard to deal with. Your problem looks simple enough that you should report it as a bug. Someone will try to fix it, and in any case it will be added to Maplesoft's massive collection of regression tests.

I think the Statistics package is using compiled routines (whose memory is not garbage collected by Maple) and they are not releasing the memory when the Maple restart command is used. This is a bug. For anyone who is interested, the best way to handle this is with a ModuleUnload procedure in your package that calls a routine to free memory. If a package has been loaded (and used) then its ModuleUnload procedure will be called by the restart command.

I've been using it since the first beta was released. Except for the Watcom compiler (not sure about that) a Maple 11 install should be completely separate from Maple 10. I haven't had any issues, although I mainly use Mac and Linux, and only rarely Windows. It is notable that from the first beta, Maple 11 has been *much* more polished than Maple 10 was at the same stage of development. I expect that Maple 10 users will have a very easy upgrade, and hopefully everyone likes the new features :)

Maple 10.05 supposedly includes some documentation changes that are not in Maple 10.06. Otherwise you can update to 10.06 directly, it includes all the changes made from 10.01 to 10.04.

The blog posts are running off the side of my small computer screen, but I think this is a reply to me :) Just to clarify how the method works: we solve the polynomial system defined by the constraints, then search among the solutions for the optimal value(s). This worked well in your first example because there were a finite number of solutions, and there were not too many solutions (70). Solving the system requires factoring a polynomial of degree < 70. In general, this method is not going to scale because the number of solutions may be exponential in the degree of the input equations and in the number of variables. Non-linear systems are inherently hard, although if the equations are sparse you can get very good real world performance. Nevertheless, Maple 10 is not going to solve this second system you posted - ever. Maple 11 is vastly improved, however even it can not hope solve the system with rational numbers. I tried it modulo a small prime and it plowed through a 225321x257313 matrix before crashing while trying to construct the next matrix, which was presumably much larger. Solving the system could involve factoring polynomials of degree 500000 - who really knows. In any case, you can't do it (yet) so I have posted the Maple 11 output for everyone to see. Maybe in five years when we have 80 core teraflop processors (to run Microsoft Office) we will do it, but for now we can't. What is shown is the very first step of PolynomialIdeals:-PrimeDecomposition.

> F := expand(map(lhs-rhs, [ConstCol, ConstRow, ConstBin])):
> infolevel[GroebnerBasis] := 5:
> G := Groebner[Basis](F, 'tord', characteristic=32003):
-> FGb
 domain: mod_int_cof
INCREASE HEAP 4000064

[1](15x37)COMPACT_NEW_LINES=1 BACKWARD=1
100/{0,0,0,0}
[2](316x556)100/{0,14,0,0}
[3](806x2278)100/{0,14,10,0}
[4](7461x13585)18.4/100/{0,14,10,40}
[5](49789x66941)0.4/14.7/28.9/43.1/57.3/71.6/85.8/100/{0
,14,10,40}
[6]INCREASE HEAP 4194368
(225321x257313)0.0/2.4/4.8/7.3/9.7/12.1/14.5/17.0/19.4/
21.8/24.2/26.7/29.1/31.5/33.9/36.4/38.8/41.2/43.6/46.1/
48.5/50.9/53.3/55.8/58.2/60.6/63.0/65.5/67.9/70.3/72.7/
75.2/77.6/80.0/82.4/84.8/87.3/89.7/92.1/94.5/97.0/99.4/
100/{0,14,10,40}
[7]INCREASE HEAP 8388672
 error in FGb
 total time:        74.045 sec
------------------------------
-> F4 algorithm
 domain: mod_int_cof   coeffs: mod_int
 ----------------------------
 basis: 50 of 50, syzygies: 36 of 36, degree: 3
 742 x 742 with 36 rhs
 symbolic preproc       0.659 sec
 linear solve           0.044 sec
 build result           0.025 sec
 14 non-zero remainders
 4 distinct leading terms
 inter reduce           0.098 sec
 10 polynomials added to basis
 ----------------------------
 basis: 60 of 60, syzygies: 93 of 93, degree: 4
 7356 x 7356 with 93 rhs
 symbolic preproc       6.655 sec
 linear solve           2.339 sec
 build result           1.615 sec
 89 non-zero remainders
 25 distinct leading terms
 inter reduce           3.690 sec
 40 polynomials added to basis
 ----------------------------
 basis: 100 of 100, syzygies: 585 of 590, degree: 5
 44863 x 44863 with 585 rhs
 symbolic preproc      94.480 sec
 linear solve         191.894 sec
 build result          67.169 sec
 551 non-zero remainders
 118 distinct leading terms
 inter reduce         172.096 sec
 178 polynomials added to basis
 ----------------------------
 basis: 278 of 278, syzygies: 3724 of 3778, degree: 6
 189189 x 189189 with 3724 rhs
 symbolic preproc     857.060 sec

If you were willing to restrict the possible values of the variables to 0 or 1, you might be able to solve this system in Magma (modulo 2). It has a dedicated data structure which makes these sorts of computations possible (although not easy). But I would suggest another approach. These problems have a way of getting difficult quickly, and although I think Maple is pretty good, it is not yet up to the task.