First, note that 'algebraic function' has a (standard) technical definition: it is a solution of a (bivariate) polynomial equation with respect to one variable. In other words, it is a generalization of square-root, as defined by "solving" y^2-x=0 for y in terms of x. So cos(theta) is not algebraic in that sense. Furthermore, Maple's type 'algebraic' is not the type of algebraic functions (that's type 'algfun'), but the type of ``algebraic expressions'', which does allow things like cos(theta). Second, it happens that while it is easy to compute Eigenvalues of matrices over fairly abstract domains, this is no longer the case for computing Eigenvalues. In the case of pure trig, there exists an algorithm -- it does not seem to be implemented (yet). You can always perform the algorithm by hand. Just write down the definition of what it is to be an Eigenvector with respect to a particular Eigenvalue, and use Maple's solve() to get the results.

What do you mean by ``solve''? Numerically or symbolically? With an example problem, we can surely help you.

We need to know a bit more about what you did to diagnose this.

f := proc(x,delta) piecewise(x=0, 0, x^delta*sin(1/x)) end; would be how I would do this. Note how I make delta an argument instead of a global [as the question has it].

Very oddly, I can't seem to either reply to your message or even send you one. The system insists on trying to send it to 'Wayne', who does not exist; selecting 'Wayne Bell' *still* tries to send it to 'Wayne', to no effect. So it looks like something is really broken behind primes somewhere.

I tried to investigate this, and what I managed to do was to crash the kernel! What I did was with(plots); Digits := 15; implicitplot(2*EllipticE(sin(beta), k)-EllipticF(sin(beta), k) = tan(beta)*sqrt(1-k^2*sin(beta)^2), k = 0 .. 0.99, beta = 4.6 .. 5.0); and poof, kernel gone. [Under Classic, M11]. Actually, first I executed the original implicitplot call, then modified it to the above, and re-executed just the plot call (in case someone tries to reproduce this). So maybe I'll move on to something else...

Your suspicion is correct - OreTools is univariate, for multivariate you need to use Ore_algebra. You almost had the translation to Ore_algebra correct. You need to change the declaration of the algebra to S := diff_algebra([x,t],func=[f,g]); and everything will work. Ore_algebra is much more general than OreTools. But, at the same time, it is much harder to use, because you need to be precise and declare everything, while OreTools is more flexible in what expressions it will accept.

I kept seeing new posts in this thread -- but never noticed that there was a second page. I think this is the first thread to get so long that it creates a second page. The real problem is that using the "Recent comments" links puts one at the bottom of page 1 rather than on page 2, [well, page 0 and page 1 to be pedantic]. So this seems like a bug in the web site software.

Either use all-numeric, or all-symbolic. So either use 1/2, or use the numeric option. These mixed symbolic-numeric cases still give Maple all sorts of difficulties -- and for good reason, since the theory for those cases is pretty much non-existant!

Since Maple is a higher-order language, if you define z as z = Switch( y->2, y->arcin(y), y->arccos(y)) (or some syntactic variant on that), it should work. I don't know the exact MapleTA syntax, but this kind of thing is easy with Maple.

First, you had a typo, you assumed that v0>0 but your system uses v[0]. Second, it is best to use assume first, then use those variables; really weird things can happen if you do it in the other order. If one removes the initial conditions (and with the assumptions first), then dsolve(sys_ode,[x(t),y(t)]) returns [{(y(t)^2/(-diff(y(t),t)+w)^2)^(1/2) = y(t)/(-diff(y(t),t)+w)}, {x(t) = (-w^2+v[0]^2-diff(y(t),t)^2+2*diff(y(t),t)*w)^(1/2)*y(t)/(-diff(y(t),t)+w), x(t) = -(-w^2+v[0]^2-diff(y(t),t)^2+2*diff(y(t),t)*w)^(1/2)*y(t)/(-diff(y(t),t)+w)}] from which is it obvious to see that y(0)=0 is going to lead to problems. It looks like that forces x(0)=0 too, but that's not the case, since D(y)(0) = w, so we really have a case of 0/0. Even the equation for y(t) is problematic too: limit(ans[1][1],t=0,right) (where ans is the expression above) (y(0)^2/(-D(y)(0)+w)^2)^(1/2) = y(0)/(-D(y)(0)+w) another 0/0. PDEtools[casesplit] applied to the system gives a big mess, but that might in fact be the 'right' equations to look at. Final remark: the 'new' algorithm for line-breaking is really making an awful mess of this equation.

As some have already posted, RealDomains can easily be fooled [ie it will miss some real roots because they don't "look" real]. If your problem has the right 'shape', the quantifier elimination might be a good way to get just the real solutions.

I can reproduce this too - it looks like a bug. Playing around with various window widths, the answer keeps sticking to the left, though the rest of it is linebroken differently. Very weird.

Check that you don't have commands in hidden blocks that cause the typesetting assistant to come up.

patmatch can be quite flaky, indets and typematch are safer. Just for robustness, I would use

extract := proc(expr)
    local atans;
    atans := convert(indets(expr, 'arctan(anything)'), list);
    map2(op, 1, atans);
end proc;

This uses op, and that is what most Maplers would do. Now, without op:

extract := proc(expr)
    local atans;
    atans := convert(indets(expr, 'arctan(anything)'), list);
    map(proc(aa) local arg; typematch(aa, 'arctan'(arg::anything)); arg; end, atans);
end proc;