You could compare the output from these various calls.

restart:
with(plots):

lambda1:=(S+sqrt(S^2+4*alpha))/(2):
lambda2:=(S-sqrt(S^2+4*alpha))/(2):

plot3d({lambda1,lambda2}, alpha=-5..5, S=-10..10);

isolate(lambda1=lambda2,alpha);

plot3d({lambda1,lambda2}, alpha=max(-1/4*S^2,-5)..5, S=-10..10);

plot3d({lambda1,lambda2}, alpha=-1/4*S^2..5, S=-10..10,
       view=[-5..5,-10..10,-10..10]);

contourplot({lambda1,lambda2}, S=-10..10, alpha=-5..5,
            contours=50, grid=[100,100]);

plottools:-transform((x,y)->[y,x])(contourplot({lambda1,lambda2},
                                                alpha=max(-1/4*S^2,-5)..5,
                                                S=-10..10, contours=50));

acer

restart:

f := x -> x^3:
g := x -> x^3:

addressof(eval(f));
                      18446744074339582038

addressof(eval(g));
                      18446744074339582126

evalb( f = g );
                             false

evalb( eval(f) = eval(g) );
                              true

is( f = g );
                             false

is( eval(f) = eval(g) );
                              true

restart:

f := x -> x^3:
g := t -> t^3:

addressof(eval(f));
                      18446744074339582038

addressof(eval(g));
                      18446744074339582126

evalb( f = g );
                             false

evalb( eval(f) = eval(g) );
                              true

is( f = g );
                             false

is( eval(f) = eval(g) );
                              true

acer

Use the currentdir command to find out where the write is being attempted. Eg, just issue

currentdir();

If that shows some location where you really shouldn't be trying to write your own files (eg. "C:/Program Files/Maple 17" then use that same command to set a more prudent location that is safer from the risk of inadvertantly clobbering one of Maple's own installed files.

For example,

currentdir(kernelopts(':-homedir'));

The location of your Maple installation is not a good place to be writing files. If you are fortunate then it will have been set write-protected by the installation process.

acer

It may happen that you want to expand the `sin` call (in the sense of using only the sum identity) but do not have at hand the terms to be temporarily frozen (via the double `subs`).

One can make a further distinction, according to which behaviour is wanted when the argument to `sin` is not a sum. It might be desired that the `sin` term be left alone, or it might be desired that it be handled in the usual `expand` manner.

Just for fun, here are two ideas. (It might be that applyrule alternatively could be used for part of it. I'd be surprised if they couldn't be improved or robustified.)

> restart:   
                                         
> expandsinsum := x -> evalindets(x,specfunc(`+`,sin),
>    q->sin(op([1,1],q))*cos(op([1,2..-1],q))
>       +cos(op([1,1],q))*sin(op([1,2..-1],q))):

> expandsinsum( 2*sin(x+Pi/4) );

                                   1/2           1/2
                           sin(x) 2    + cos(x) 2

> expandsinsum( 2*sin(2*x+Pi/4) );

                                   1/2             1/2
                         sin(2 x) 2    + cos(2 x) 2

> expandsinsum( 2*sin(2*x+4*k) );

                   2 sin(2 x) cos(4 k) + 2 cos(2 x) sin(4 k)

> expandsinsum( 2*sin(4*k) ); # not a sin of a sum; does nothing

                               2 sin(4 k)

> restart:                                                     

> expandtrigsum := x -> eval(expand( x,                        
>    op(map(op@op,indets(x,'specfunc(`+`,{sin,cos,tan})'))) )):

> expandtrigsum( 2*sin(x+Pi/4) );                              

                                   1/2           1/2
                           sin(x) 2    + cos(x) 2

> expandtrigsum( 2*sin(2*x+Pi/4) );                            

                                   1/2             1/2
                         sin(2 x) 2    + cos(2 x) 2

> expandtrigsum( 2*sin(2*x+4*k) );                             

                   2 sin(2 x) cos(4 k) + 2 cos(2 x) sin(4 k)

> expandtrigsum( 2*sin(4*k) ); # not trig of a sum; behaves like expand

                                      3
                      16 sin(k) cos(k)  - 8 sin(k) cos(k)

It's possible, then, to craft your own procedures which can produce a variety of more general behaviour.

acer

You wrote, "actually, my expectation is simple, just find back the original matrix from eigenvector and eigenvalue."

Your Matrix happens to be diagonaliable, and there are three linearly independent eigenvectors associated with its three eigenvalues. The 3x3 Matrix of its eigenvectors (as columns, like the `Eigenvectors` command returns) is invertible.

The eigen-solving, or the reconstruction, can be done for this example either as an exact symbolic or as an approximate floating-point computation.

restart:

with(LinearAlgebra):

A := `<|>`(`<,>`(1, 2,3), `<,>`(2, 3, 0), `<,>`(2, 0, 0));

                                [1  2  2]
                                [       ]
                           A := [2  3  0]
                                [       ]
                                [3  0  0]

v, EigenVector1:= Eigenvectors(A):

map(radnormal,EigenVector1.DiagonalMatrix(v).EigenVector1^(-1));

                              [1  2  2]
                              [       ]
                              [2  3  0]
                              [       ]
                              [3  0  0]

v, EigenVector1:= Eigenvectors(evalf(A)):

map(simplify@fnormal,EigenVector1.DiagonalMatrix(v).EigenVector1^(-1));

               [1.000000000  2.000000000  2.000000000]
               [                                     ]
               [         2.  3.000000000           0.]
               [                                     ]
               [3.000000000           0.           0.]

Note that not all Matrices have a full set of linearly independent eigenvectors which can form such an invertible Matrix. But even if that Matrix of eigenvectors is not invertible then the vectorized definition of eigenvalues & eigenvectors (A.x=lambda.x) can still hold. Ie, the following is very similar to the above, but both sides are not right-multiplied by the inverse of `EigenVector1` Matrix.

v, EigenVector1:= Eigenvectors(evalf(A)):

map( simplify@fnormal, A.EigenVector1 - EigenVector1.DiagonalMatrix(v) );

                            [0.  0.  0.]
                            [          ]
                            [0.  0.  0.]
                            [          ]
                            [0.  0.  0.]

v, EigenVector1:= Eigenvectors(A):

map( radnormal, A.EigenVector1 - EigenVector1.DiagonalMatrix(v) );

                              [0  0  0]
                              [       ]
                              [0  0  0]
                              [       ]
                              [0  0  0]

acer

By using cylindrical coordinates one can easily construct either a whole cone or a partial cone having a round base.

R, H := 3.2, 4.7;

plot3d(R*(H-h)/H, th=-Pi..Pi, h=0..H, coords=cylindrical);

plot3d(R*(H-h)/H, th=-3*Pi/2..0, h=0..H, coords=cylindrical, view=[-5..5,-5..5,0..H]);

Other options such as the 'view',etc, may also be supplied.

In contrast, using plottools:-cone produces only a full cone, while using the default rectangular coordinates (with trig functions) produces a structure which renders with straight edges on the polygonal primitives around its base.

acer

An alternate way might be,

f := x1^2/((x2^3)*(x3^2)):

subsindets(f, name^negint, q->1/cat(op(1,q),b)^op(2,q));

                           2    3    2
                         x1  x2b  x3b 

acer

There are various ways to get it. It's not clear whether your expression will always be so simple, or whether it might have some symbolic coefficient, whether it is always a ratio of multivariable polynomials, etc. How simple you can make it will depend on how restricted is the nature of the expression.

ee:=x^2*y^3/z^7:

(t->zip(`^`,t,map2(degree,ee,t)))([indets(ee,And(name,Non(constant)))[]]);

                          [ 2   3  1 ]
                          [x , y , --]
                          [         7]
                          [        z ]

[op(ee)];

                          [ 2   3  1 ]
                          [x , y , --]
                          [         7]
                          [        z ]

[indets(ee,And(name,Non(constant))^anything)[]];

                          [ 2   3  1 ]
                          [x , y , --]
                          [         7]
                          [        z ]

As just one simple example of how these behave for a slightly more general expression,

ee:=Pi^3*x^2*y^3/z^7:

(t->zip(`^`,t,map2(degree,ee,t)))([indets(ee,And(name,Non(constant)))[]]);

                          [ 2   3  1 ]
                          [x , y , --]
                          [         7]
                          [        z ]

[op(ee)];

                       [  3   2   3  1 ]
                       [Pi , x , y , --]
                       [              7]
                       [             z ]

[indets(ee,And(name,Non(constant))^anything)[]];

                          [ 2   3  1 ]
                          [x , y , --]
                          [         7]
                          [        z ]

So you may be able to figure out whether `op` alone is enough.

acer

If you used the syntax,

(exp(x)-1)(1-exp(-x))

then you probably wanted this instead,

(exp(x)-1)*(1-exp(-x))

I don't know whether either of these will get you what you want for more constrained examples, but it might give you some ideas.

restart:

s:={A>E,F>Z,F<P,Z>E,P<A}:

sort([s[]],(a,b)->coulditbe(op(2,a)<op(1,b) or op(1,a)<op(2,b))=true) assuming op(s);

                    [E < A, E < Z, Z < F, F < P, P < A]

sort([s[]],(a,b)->is(op(2,a)<op(1,b) or op(1,a)<op(2,b))=true) assuming op(s);

                    [E < A, E < Z, Z < F, F < P, P < A]

acer

Attached is an example. The commands are in the Action code behind the buttons.

The basic idea is to use the DocumentTools:-SetProperty command and the properties for (an animation as the value of) a PlotComponent listed here.

animatortask.mw

I'm not sure how well the dial (approx. frames/sec) will work in general. It may be better to give up the FPS idea and just go with a frame-delay instead.

One of the actions that I miss is the ability to do a distributed divide (or multiply). By distributed I mean expanded. Sometimes I want the divided (or multiplied) factor distributed across a sum of terms, and sometime I don't. So a choice would be nice.

I find it awkward to cancel leading minus signs on both sides of an equation.

And I'd like to be able to customize the priorities, so that `normal` (which must seem like magic, and be uninstructive to many students) didn't supercede more understandable entries such as for expand,factor,combine,etc.

Here is a humble attempt, hopefully in the direction you were aiming.

spmanip.mw

acer

restart:

ee:=(exp(a+b)+exp(a+c))*exp(-a):

expand(ee);

                        exp(b) + exp(c)

acer

If you want to join the plotted data values by lines, then you can sort w.r.t. the first column of the pair.

A:=ArrayTools:-RandomArray(4,4);

plot(sort(convert(A[..,[1,3]],listlist)));

plot(A[sort(A[..,1],output=permutation),[1,3]]);

If you only want a point-plot (no joining lines) then it's easier.

plot(A[..,[1,3]],style=point);

acer

Your Maple procedure `mp` is heavy in terms of producing collectible garbage. And it's not just the sorting. The repeated unioning of temporary sets, conversion to temporary tables, and disposing of all these (memory managment) is expensive. 

That can be illustrated with a modification to your original `mp` procedure to get something like the following, where the partial results (computed in the loops within just a single non-recursed call to the central procedure) are instead stored in a single table whose entries are extracted into a set only once just prior to the procedure return.

Since `mp3` is recursive it still entails quite a bit of switching between temp sets and temp tables and so this modified version is still prone to slowdown as the problem size grows large -- but the idea is just to show that reducing it improves performance.

mp3 := proc(n)
    option remember;
    local count, rec, onef, res, f, asg, targ, t;
    if n=1 then return {}; fi;
    onef := op(2, ifactors(n))[1];
    rec := mp3(n/onef[1]);
    if nops(rec) = 0 then return {[n=1]} fi;
    count:=0:
    for f in rec do
        t := table(f);
        targ := onef[1];
        if type(t[targ], integer) then
            t[targ] := t[targ] + 1
        else
            t[targ] := 1;
        fi;
        count:=count+1: res[count]:=op(op(t));
        for asg in f do
            t := table(f);
            targ := onef[1]*op(1, asg);
            if type(t[targ], integer) then
                t[targ] := t[targ]+1;
            else
                t[targ] := 1;
            fi;
            if t[op(1,asg)]>1 then
                t[op(1,asg)] := t[op(1,asg)]-1;
            else
                t[op(1,asg)] := evaln(t[op(1,asg)]); 
            fi;
            count:=count+1: res[count]:=op(op(t));
        od;
    od;
    {entries(res,':-nolist')[]};
end:

On my machine your original `mp` handled 9! in about 35sec, and the edited `mp3` above took 1.2sec, while Factorings [due to Kitonum, Joe Riel, and Carl Love] took 0.14sec. Of course, more important than just single timings are the performance as the problem size grows.

acer