It evokes mixed feelings in me. Certainly it was full of rather useful code. However, when Maplesoft "took it over" to include in the product, we couldn't just include it as-is, we had to make sure that a minimum level of quality and consistency was met by all packages. And that turned out to be a huge amount of work. I led that effort, and it involved work by a lot of people over several months to get all the help pages cleaned up, all the code to 'work' (it had bit-rotted a lot more than we'd expected). It does seem like Maple users did appreciate the effort though. The Application Center was an interesting political and technological solution to the maintenance of user-shared code. If the code shipped with Maple, then Maplesoft had to ensure a minimum quality level. But if it was on the App Center, then it was up to the authors of the packages to ensure that they did not bit-rot. [The fact is that a lot of them have bit-rotted, the grand claims to backwards compatibility by Maplesoft notwithstanding.] It was also nice because it was the first foray of Maplesoft into using the web constructively, and it really was a success. It was both useful for users, gave some prestige to some avid Maple fans&developers, and was a useful marketing too. It also meant that this app center could be updated continuously instead of having to wait through release cycles. In another 5 years, maybe I'll be able to tell the full story of the decline and rebirth of the app center. Hint: a lot of the app center consists of .mws files.

When you ask solve(x=a,x); Maple answers 'a', even when 'a' is rather complicated -- is that so surprising? What is surprising is that, in some cases solve(x=a,x); will ``simplify'' 'a' before returning the answer. And in the case of a labeled RootOf, this can mean an expansion and/or a conversion to explicit form. That is weird - and was most likely an explicit design decision at some point. It's just weird when you look at it in these stark terms. Another point: why do you say that + and - sqrt(3) are the 'correct' answers? Says who? Labels for RootOf are like a 'uniqueness stamp'; they have only one purpose, and that is to ensure that two otherwise identical RootOfs are treated as independent. Put another way: it used to be that in Maple, long enough ago, solve({x^2=2,y^2=2},{x,y}) would return 2 solutions instead of the (correct) 4, because of problems with not being able to have independent RootOfs. Actually, sometimes it would also return too few answers, for similar reasons. Labels solve that problem (and are the only way to solve that problem, short of always using 'index', for high degree polynomials). The previous thread went over why there is a mixture of indexes and labels (ie history).

LinearAlgebra is usually a better option - and has the same functionality.

[I don't have the manual handy]. I think the routine you want is like

daniel2 := proc(x::list)
    local l;
    l := combinat[choose](x,2);
    Vector(nops(l), (x->l[x,1]+l[x,2]));
end;

You should not trust that dsolve/numeric's output will be positionally the same always. Could you show us a larger piece of code? With the actual DE defining 'p', I am sure we can help you. BTW, the issue with fsolve seems like a bug -- you should put together a stand-alone report and submit it to support@maplesoft.com

What is your bigger goal, your application? We can help you with all these micro-steps, but I get this strange feeling that these steps are sub-optimal, and that a different approach altogether might be easier in Maple.

1. No, but this is not relevant, because the output of fsolve/solve in in just the right formal to use with 2-argument eval, which is what you want to use anyways. 2. You don't need an array, a list will be fine here. l := [ seq( eval([x,y], fsolve({x+y=n+6,x*y=10},{x,y})), n=1..10) ]; plot(l); 3. Yes, definitely. See ?XMLTools,Serialize ?Spread (or the various GUI commands to export from tables to spreadsheets) ?writedata, ?fprintf and others. Somewhat surprisingly, there is a wonderful ImportData Maplet, but no ExportData companion!

Right when you get the error, you should immediately type tracelast; on an empty input line. That will give you a stack trace of what the values of all the locals at the point where the error occured. This should give you a clue as to what is going wrong. With the information you give above, I can't being to make a guess.

You should answer Allan's query, as he will be able to help you solve the 'real' problem you are encountering. What you are seeing is raw Maple error strings when under a try/catch or a traperror. Instead of printing nicely in that situation, in a high-printlevel setting you see the raw components, which can be daunting and confusing. But mostly it means that an error occured and something higher up trapped the error. That particular error is put out, I believe, by an rtable access function when you try to store something of the wrong type in an rtable. Why that occurs, Allan can help with.

Robert shows how to force Maple into giving you the huge, ugly classical formulas for the closed-form roots. These are computationally untractable as well as ugly, and should not really be used in applications. I was going to show a neat trick (via gfun[algeqtodiffeq]) to get the problem solved via ODEs, but encountered a bug while doing that. It's really too bad, because for degree 3 it produces a really nice cos-arctan formula for roots which is much more tractable that the classical one.

So if you want to plot a bunch of numbers store in an array, simplest is to use listplot3d. Assuming your data is in an array named 'a' (since using the name 'array' is a really bad idea):

plots[listplot3d]([seq([seq(a[i,j],i=1..10)],j=1..10)]);

Another possibility is to use plots[matrixplot], ie

plots[matrixplot](a);

may well give you what you want.

If coeff cannot directly see that ``variable'', then the coefficient will be 0, same with select. To get things in the proper shape, here is the magic incantation that works:

collect(combine(expand(cc)), phi);

and then you can do

coeff(%, phi^(2*j-5));

which will work. This may look like a basic question, but it is not -- you are lucky this works at all! Computer Algebra systems do not (yet) work very well with symbolic exponents, something humans can do more easily.

For non-linear DEs, there is a good chance that there is no closed-form solution. Maple indicates this by returning no solution at all - which can certainly look like "nothing happens". You can use

infolevel[dsolve] := 3;

to get dsolve to be much more verbose about what it is doing.

B := A[[2,4,5],[2,4]];

See ?MVextract for details.

If you post a version of your input that we can cut&paste ourselves, I believe you'll have a number of people here who can help you. Also, if you know some extra information (like which parameters are real and/or positive and/or integers), that typically makes a huge difference on whether Maple can find an answer or not. Withholding information from Maple is one of the best ways to ensure that your integral will return unevaluated.