Perhaps someone else will be able to help, but reading your description of the problem I couldn't understand what you want to do. Also, your code is not in the right order because lambda depends on a and A. Also, your g is simply f(x).

On my system (Windows7-64,Maple14) I get the same output for these:

plot(tan(x),discont=true);

smartplot(tan(x));

So smartplot is not "smart" enough to guess that you want to see:

view=[-10..10,-10..10]

I'm reminded of the following exchange, which comes up near the top when you search the mapleprimes archives -- did you search them before posting? The new mapleprimes has much improved search capabilities, much much improved.


http://www.mapleprimes.com/questions/36006-Newb-Question-Tana-Doesnt-Appear-To-Plot-Correctly%23comment60294

The American Scientist magazine had an article on this and related problems recently. You may find it useful. Reference:

Theodore P. Hill, "Knowing When To Stop", March-April, pages 126-133, 2009.

you should be able to google your way to the source.

No, I'm still stuck.

To sum up, I'm trying to write a procedure/function that will take a Vector of Multivariate Polynomials in X[i] and extract the coefficients in a predefined order and store them in a Matrix. I've managed to extract coefficients into a Matrix, but I'm unable to get the coefficients ordered the way I'd like them to be.

Given a Vector of polynomials like:

a0 + a1*X[1] + a2*X[2] + a3*X[1]^2 + a4*X[2]^2 + a5*X[1]*X[2]

I wish to get a matrix of the coefficients in the following order:

[a0,a1,a2,a3,a4,a5]

After several hours of trying everything I could think of, I can't get the coefficients in the order desired.

Help/coeffs says

For multivariate polynomials, you may need to use collect with `distributed`.

The example given is

coeffs(collect(p,[x,y],'distributed'),[x,y]);

I've tried to do just that. But in my procedure, whether I apply coeffs on collect, whether I apply coeffs on sort or coeffs on sort and collect, I always get the same order, and it's not the order I expect.

I'll appreciate any pointers.

Below my best effort:

V := X-> Vector([[a4*X[2]^2+a1*X[1]+a5*X[1]*X[2]+a2*X[2]+a3*X[1]^2],[(b1*X[1]+b2*X[2])^2]]): V(X);

ExtractCoeffs := proc(V,X)
local d,i;
d:=[op(1,V(X))][1];
Matrix([seq([coeffs(sort(
expand(V(X)[i])                      #expand vector
,[seq(X[d+1-i],i=1..d)],'ascending') #sort options
,[seq(X[i],i=1..d)]                  #coeffs option
)],i=1..d)]);
end proc:
ExtractCoeffs(V,X);

ExtractCoeffs := proc(V,X)
local d,i;
d:=[op(1,V(X))][1];
Matrix([seq([coeffs(sort(collect(
expand(V(X)[i])                      #expand vector
,[seq(X[i],i=1..d)],'distributed')   #collect options
,[seq(X[d+1-i],i=1..d)],'ascending') #sort options
,[seq(X[i],i=1..d)]                  #coeffs option
)],i=1..d)]);
end proc:
ExtractCoeffs(V,X);

ExtractCoeffs := proc(V,X)
local d,i;
d:=[op(1,V(X))][1];
Matrix([seq([coeffs(collect(
expand(V(X)[i])                      #expand vector
,[seq(X[i],i=1..d)],'distributed')   #collect options
,[seq(X[i],i=1..d)]                  #coeffs option
)],i=1..d)]);
end proc:
ExtractCoeffs(V,X);

For the top row, all 3 procs yield: [a2,a1,a3,a4,a5]
For the bottom row, all 3 procs yield: [b1^2,b2^2,2*b1*b2,0,0]
The bottom ranking of coefficients is what I expect/want,
The top ranking I was expecting: [a1,a2,a3,a4,a5] instead

... Or am I so tired that I don't make any sense anymore?

@mikealpha85 

your x comes out in a complicated format, so for simplicity I copy-pasted it and removed unnecessary bits. You can achieve a similar result using op(2,x) and other ways. Refer to the Help menu.

You want to solve x for the theta dots:

x := (sin(theta[1](t))*(diff(theta[1](t), t))*cos(theta[2](t))*sin(theta[3](t))+cos(theta[1](t))*sin(theta[2](t))*(diff(theta[2](t), t))*sin(theta[3](t))-cos(theta[1](t))*cos(theta[2](t))*cos(theta[3](t))*(diff(theta[3](t), t))-sin(theta[1](t))*(diff(theta[1](t), t))*sin(theta[2](t))*cos(theta[3](t))+cos(theta[1](t))*cos(theta[2](t))*(diff(theta[2](t), t))*cos(theta[3](t))-cos(theta[1](t))*sin(theta[2](t))*sin(theta[3](t))*(diff(theta[3](t), t)))*(d[4]+rho*sin((1/2)*theta[4](t)))+(1/2*(-cos(theta[1](t))*cos(theta[2](t))*sin(theta[3](t))+cos(theta[1](t))*sin(theta[2](t))*cos(theta[3](t))))*rho*cos((1/2)*theta[4](t))*(diff(theta[4](t), t))+cos(theta[1](t))*(diff(theta[1](t), t))*(d[3]+rho*sin((1/2)*theta[3](t)))+(1/2)*sin(theta[1](t))*rho*cos((1/2)*theta[3](t))*(diff(theta[3](t), t))-sin(theta[1](t))*(diff(theta[1](t), t))*a[2]*cos(theta[2])-cos(theta[1](t))*(diff(theta[1](t), t))*(d[2]+rho*sin((1/2)*theta[2](t)))-(1/2)*sin(theta[1](t))*rho*cos((1/2)*theta[2](t))*(diff(theta[2](t), t)), 2 = (-cos(theta[1](t))*(diff(theta[1](t), t))*cos(theta[2](t))*sin(theta[3](t))+sin(theta[1](t))*sin(theta[2](t))*(diff(theta[2](t), t))*sin(theta[3](t))-sin(theta[1](t))*cos(theta[2](t))*cos(theta[3](t))*(diff(theta[3](t), t))+cos(theta[1](t))*(diff(theta[1](t), t))*sin(theta[2](t))*cos(theta[3](t))+sin(theta[1](t))*cos(theta[2](t))*(diff(theta[2](t), t))*cos(theta[3](t))-sin(theta[1](t))*sin(theta[2](t))*sin(theta[3](t))*(diff(theta[3](t), t)))*(d[4]+rho*sin((1/2)*theta[4](t)))+(1/2*(-sin(theta[1](t))*cos(theta[2](t))*sin(theta[3](t))+sin(theta[1](t))*sin(theta[2](t))*cos(theta[3](t))))*rho*cos((1/2)*theta[4](t))*(diff(theta[4](t), t))+sin(theta[1](t))*(diff(theta[1](t), t))*(d[3]+rho*sin((1/2)*theta[3](t)))-(1/2)*cos(theta[1](t))*rho*cos((1/2)*theta[3](t))*(diff(theta[3](t), t))+cos(theta[1](t))*(diff(theta[1](t), t))*a[2]*cos(theta[2](t))-sin(theta[1](t))*a[2]*sin(theta[2](t))*(diff(theta[2](t), t))-sin(theta[1](t))*(diff(theta[1](t), t))*(d[2]+rho*sin((1/2)*theta[2](t)))+(1/2)*cos(theta[1](t))*rho*cos((1/2)*theta[2](t))*(diff(theta[2](t), t)), 3 = (cos(theta[2](t))*(diff(theta[2](t), t))*sin(theta[3](t))+sin(theta[2](t))*cos(theta[3](t))*(diff(theta[3](t), t))-sin(theta[2](t))*(diff(theta[2](t), t))*cos(theta[3](t))-cos(theta[2](t))*sin(theta[3](t))*(diff(theta[3](t), t)))*(d[4]+rho*sin((1/2)*theta[4](t)))+(1/2*(sin(theta[2](t))*sin(theta[3](t))+cos(theta[2](t))*cos(theta[3](t))))*rho*cos((1/2)*theta[4](t))*(diff(theta[4](t), t))-a[2]*cos(theta[2](t))*(diff(theta[2](t), t))+(1/2)*rho*cos((1/2)*theta[1](t))*(diff(theta[1](t), t));

sys := solve({x}, {diff(theta[1](t),t),diff(theta[2](t),t),diff(theta[3](t),t),diff(theta[4](t),t)});

Try it out, the output is long.

I really ought to have experimented further before posting. And read the Help files inside out too, right? I'd found the following behavior of sort,plex. It's kind of different from what intuition would lead one to expect.

Here's an example from the Help menu:

f := 4*x^3 + 5*x^2*z^2 + 2*x*y^2*z + 1:
sort(f,order=plex(x,y,z),'ascending');
sort(f,order=plex(z,y,x),'ascending');

                          2        2  2      3
                 1 + 2 x y  z + 5 x  z  + 4 x

                        3        2        2  2
                 1 + 4 x  + 2 z y  x + 5 z  x

It's kind of hard to tell right away if that's the expected behavior. The x comes early in the ranking in both cases, but the earlier case has a term of order 4 (x*y^2*z) before a term of order 3 (x^3). The latter ranking is more like what I would expect. More evidence below.

An easier example to read, made up by me:

p := 2*y*z + 4*y^2 + x + 5*x*y +3*x^2 + 1 +z:
sort(p,order=plex(x,y,z),'ascending');
sort(p,order=plex(z,y,x),'ascending');

                               2                  2
            1 + z + 2 y z + 4 y  + x + 5 x y + 3 x
                       2              2            
            1 + x + 3 x  + 5 y x + 4 y  + z + 2 z y

The second line gets the x before the y and before the z. Just what I want. But it's funny that the plex command requires a reverse order from that, plex(z,y,x).

so plex(z,y,x) will arrange the arguments as follows: x,y,z.

There's nothing illogical about it.

But ...it's rather counterintuitive I'd say. As it turns out, I have just found out that it is NORMAL BEHAVIOR (see below). I think the Help menu could be improved by sort of emphasizing this subtle aspect of the use of plex.

Sorry to be a bore.

Patrick.

I'll copy the relevant bit from the Help menu:

from help/sort

Other monomial orders can be specified by using the order=o calling sequence. The supported orders are:
  plex(x1, ..., xn) - lexicographic order
  grlex(x1, ..., xn) - graded lexicographic order
  tdeg(x1, ..., xn) - graded reverse lexicographic order
  for indeterminates x1, ..., xn. For a description of these orders, see Monomial orders for multivariate polynomials.
When sorting polynomials the optional argument ascending or descending may be specified to put the terms into ascending or descending order, respectively. The default is descending order, which puts higher-degree terms before lower-degree terms.

And so following up on the reference to Monomial orders for multivariate polynomials above:

plex(x[1],...,x[n]) pure lexicographic order with x[1] > x[2] > ... > x[n]. This order is used to eliminate variables and solve systems of polynomial equations, however the resulting Groebner bases can be huge. Monomials are compared first by their degree in x[1], with ties broken by degree in x[2], etc.

The key to the behavior I was observing is in this convention: x[1] > x[2] > ... > x[n].

You're more liekly to get useful replies if you post your code and make the question a bit more precise.

From the image you post, you may want to try something like:

map(diff,A,t);

select(has,%, diff);

Your post is dated 8 October. Today is 4 November. I don't mean to bump up an oldish post, but yours appears near the top of the list of "unanswered" posts, so I'll proceed under the assumption that it has not been answered and that an answer is still desired. It's all pretty straightforward, so I hope you had it figured it out on your own a while ago. But for the record, here's the full answer. You can then use your boundary conditions to determine the constants _F1 and _F2.

pde := diff(A(r, theta), r, r)+(diff(A(r, theta), r))/r+(diff(A(r, theta), theta, theta))/r^2:
pdsolve(pde);
   A(r, theta) = _F1(I ln(r) + theta) + _F2(-I ln(r) + theta)

The following is a modified version of a trick shown by Robert Israel on MUG:

MyJacobian := (F,X) -> Matrix([seq([seq(diff(f,x),x=X)], f=F)]);
MyJacobian(Fvec,Xvec);

It seems to work and takes vectors. Any reason not to go down that road?

@Alejandro Jakubi 

thanks Alejandro,

if I play around with the paramater values, I seem to consistently get a plot of the difference of the order of 1e-19, but "simplify" does not seem to confirm the truth of the hypothesized equality for too many values.

Following up on your lead, I tried

is(expr1=expr2) assuming positive;

but this returns FAIL, rather than false...

Here (http://en.wikipedia.org/wiki/Diagonalizable_matrix) it states:

An n-by-n matrix A is diagonalizable over the field F if it has n distinct eigenvalues in F, i.e. if its characteristic polynomial has n  distinct roots in F.

restart:
A := Matrix([[1,sqrt(2),-sqrt(6)],[sqrt(2),2,sqrt(3)],[-sqrt(6),sqrt(3),0]]);

                         [          1/2      1/2]
                         [  1      2       -6   ]
                         [                      ]
                    A := [ 1/2              1/2 ]
                         [2         2      3    ]
                         [                      ]
                         [  1/2     1/2         ]
                         [-6       3         0  ]

LinearAlgebra:-JordanForm(A);
LinearAlgebra:-CharacteristicPolynomial(A,x);

                3      2                 1/2  1/2  1/2
               x  - 3 x  - 9 x + 15 + 2 6    2    3

solve(%,x);

                               -3, 3, 3

In other words, the root 3 is repeated, so -- if the theorem stated in wikipedia is correct -- the matrix is not (necessarily) diagonalizable.
 

with(plots):
p:=plot3d(Re(ln(x+I*y)), x=-2.4..2.4, y=-2..2, axes=box):
display(p, view=[-2.4..2.4, -2..2, -3..4]);

I get the same problem with 13.01 in Windows XP (I haven't yet installed .02).

This has always happened to me with 3D plots, from Maple 10 and possibly earlier to Maple 13, in Classic (I don't know about Standard, as I don't use it). It's very annoying and I don't know what to do to avoid the problem. It seems to be related to the angle of view, so that if you rotate the image a little it may not happen anymore. What I do is export the image and view it with another software...

Update: What I mean is that when you create the figure, add something like ",orientation=[-120,60]" to the display command, and it will rotate the figure according to the angles you specify. Play around with the values until the figure no longer vanishes when you click on it. That's my workaround -- hope it works for you too.

Note also that f(0) involves a division by zero, while f(-1)=-ln(-1) is a complex number. Perhaps you want to restrict x>0.