It's really hard to suggest things without more detail. I would start in "preferences" and set "use hardware acceleration for plots" to off. Some video card drivers also create problems for Maple, you might try testing updated drivers. In any case, contact Maplesoft support.

If the systems are triangular there are quite a few ways to estimate which will be easy and which are hard. The simplest method is to put them all in a list and sort by length, ie: sort(..., 'length'). You can also crudely estimate the number of solutions by computing the maximum degree in each variable (assuming the equations are polynomials) and multiplying them together. For example:

sysdeg := proc(eqns) local i, j; option system, remember;
  mul(max(seq(degree(i,j), i=eqns)), j=indets(eqns));
end proc;
sols := [ {x^3-y^2+1, y^3+y+1}, {x^2-y, y^4+y+1} ];
sort(sols, proc(a,b) evalb(sysdeg(a) <= sysdeg(b)) end proc);

Otherwise you can use the SolveTools[SortByComplexity] command. Note that that command sorts into decreasing order, so the most complex systems will be first.

In Maple 10 and lower I would try the diffalg package first. Can you post an example for me to look at ?

The plot option scaling=constrained will set a 1:1 ratio (the aspect ratio) between the horizontal and vertical axes. There's also a button you can click (with a little 1:1 on it) if you click on the plot.

The plot option scaling=constrained will set a 1:1 ratio (the aspect ratio) between the horizontal and vertical axes. There's also a button you can click (with a little 1:1 on it) if you click on the plot.

This is close, but I think the arguments of the generated procedure are unordered. I suggest using sort(convert(map(rhs,rtable_elems(U) union rtable_elems(V)),list), 'lexorder'). Still the point is that there is no good way to automatically generate procedures which take matrices as input.

This is close, but I think the arguments of the generated procedure are unordered. I suggest using sort(convert(map(rhs,rtable_elems(U) union rtable_elems(V)),list), 'lexorder'). Still the point is that there is no good way to automatically generate procedures which take matrices as input.

Yes. Computing Groebner bases is exponential space, because in the worst case it is possible to have basis elements with that many terms. In practice this doesn't really happen, and the polynomials in the resulting basis are sparse (compared to the total number of monomials up to their degree). This paper has a decent introduction, however there are a lot of results in this area which depend on the properties of the polynomial system.

There is a whole package dedicated to linear algebra. To load it, type

with(LinearAlgebra);

This will also display a list of commands. To surpress this list, use a colon instead of a semi-colon. Type

?LinearAlgebra

to get a help page showing the most commonly used commands. You may also be interested in the VectorCalculus package.

There is a whole package dedicated to linear algebra. To load it, type

with(LinearAlgebra);

This will also display a list of commands. To surpress this list, use a colon instead of a semi-colon. Type

?LinearAlgebra

to get a help page showing the most commonly used commands. You may also be interested in the VectorCalculus package.

What you want is simplification with respect to side relations. For example:

expr := a*e^3 + 3*a*e^2*f + 3*a*e*f^2 + a*f^3 + 2*b*e^2 + 4*b*e*f + 2*b*f^2 + 4*c*e + 4*c*f + 8*d;
rels := {a*e^3 + b*e^2 + c*e + d = 0};
simplify(expr, rels);

Since you have only one side relation this will divide the expression by the relation, using multivariate polynomial division. It is equivalent to applying a rewrite rule to rewrite the individual terms. The result depends on which term in the relation is considered the most significant. For example, if d is the most significant term, then the rule will replace d = -a*e^3 - b*e^2 - c*e. You can affect this choice with a third argument which is an order on the variables. Here are some examples, see the help page ?simplify,siderels for more.

simplify(expr, rels, [a,b,c,d,e]);
simplify(expr, rels, [d,a,b,c,e]);
simplify(expr, rels, [b,a,c,d,e]);

Note that if you have more than one relation, simplify/siderels will compute a Groebner basis for the relations to obtain all the algebraic consequences and ensure that the division process terminates.

What you want is simplification with respect to side relations. For example:

expr := a*e^3 + 3*a*e^2*f + 3*a*e*f^2 + a*f^3 + 2*b*e^2 + 4*b*e*f + 2*b*f^2 + 4*c*e + 4*c*f + 8*d;
rels := {a*e^3 + b*e^2 + c*e + d = 0};
simplify(expr, rels);

Since you have only one side relation this will divide the expression by the relation, using multivariate polynomial division. It is equivalent to applying a rewrite rule to rewrite the individual terms. The result depends on which term in the relation is considered the most significant. For example, if d is the most significant term, then the rule will replace d = -a*e^3 - b*e^2 - c*e. You can affect this choice with a third argument which is an order on the variables. Here are some examples, see the help page ?simplify,siderels for more.

simplify(expr, rels, [a,b,c,d,e]);
simplify(expr, rels, [d,a,b,c,e]);
simplify(expr, rels, [b,a,c,d,e]);

Note that if you have more than one relation, simplify/siderels will compute a Groebner basis for the relations to obtain all the algebraic consequences and ensure that the division process terminates.

Try either of the following: plot3d(f, -10..10, -10..10); plot3d(f(x,y), x=-10..10, y=-10..10); They do the same thing. In the first case we construct a 3d plot of the surface z = f(x,y) by letting the first and second arguments range from -10 to 10. In the second case we construct the expression f(x,y), literally by plugging in x and y as the first and second arguments to f, then letting x and y range from -10 to 10. In your example the first case is more convenient, but the second case is useful if you have an expression, like a polynomial, and you don't want to make a function (although that is easy too, use the unapply command).

No, I think there's a reason why Maple has trouble with this example. Higher settings of initmesh don't seem to make a difference. Do you know what the solution is ? Is it continuous ?

The help page ?dsolve,numeric_bvp,advanced has some good info on this. Essentially the problem is that the coefficient of a higher order derivative ( 0.01*x''(t) ) is too small, so the Newton iteration won't converge initially. One way to work around this problem is to introduce a parameter lambda that changes another problem (that is well conditioned) into your problem (which is nasty). This is called a continuation. dsolve/numeric supports bvp continuation, and the convention is that lambda should go from 0 to 1, where 0 is the perturbed problem and lambda=1 gives the original problem. For example, your original problem is:

ode := { 1/100*diff(x(t),[t$2]) + diff(x(t),t)^2 = 0 , x(0)=1,x(1)=0};

We might change that to

newode := { (1/100 + 50/100 - 50/100*lambda  )*diff(x(t),[t$2]) + diff(x(t),t)^2 = 0 , x(0)=1,x(1)=0};

Then we could use:

S:=dsolve(newode,x(t),type=numeric,method=bvp[midrich],continuation=lambda):

This is essentially what you need to do. Unfortunately when I tried it this didn't converge either. You can play with the parameter values and increase the setting of Digits to get farther into the problem, but I wasn't able to solve it. You can try other continuations, and set initmesh=1000 or 5000 to refine the mesh.