This is much cruder than _Maxim_'s suggestion, but happens to work here.

I include some steps that are not necessary,

restart;

eu := -2*n^2*B^2+2*n*B^2*p-2*n*B^2*p^2+n*B^2-B^2*p+B^2*p^3+n*c*d:                          

algsubs(p^2=freeze(p^2-p+n)+p-n,
        expand(algsubs(p^3=freeze(p^3-p+n)+p-n,
                       expand(eu))));

                       2                2
                   -2 B  n freeze/R0 + B  freeze/R1 + c d n

collect(%,[freeze(p^2-p+n),freeze(p^3-p+n)]);

                       2                2
                   -2 B  n freeze/R0 + B  freeze/R1 + c d n

thaw(%);

                       2   2             2   3
                 -2 n B  (p  + n - p) + B  (p  + n - p) + n c d

Some of those apparent numbers in the input Matrix are not really numbers. But rather, they are just names that just look like the numbers, and so do not resolve mathematically. Some of the apparent zeroes in the input Matrix are lime that.

I've seen others have the same problem when using the Matrix palette, in particular with Maple 2017.

I suggest you manually delete the entries in the Matrix input, and then re-enter them.

Or use the `<<..>>` or Matrix commands instead of the palette to enter your Matrices. 

 

I don't really understand what rule you might be thinking of, for including terms like z^w .

But is this the kind of thing you mean? (It is not guaranteed to always produce "difference parametric coefficients", but most of the time it does.)

>  restart; >  randomize(): >  gen_p:=proc(vars::list(name),             params::list(name),             {varterms::posint:=4,              vardeg::posint:=2,              paramterms::posint:=1,              paramdeg::posint:=2,              paramcrng::range(nonnegint):=1..10})   local p_xyz,L,L_abc,L1_abc,L2_abc,t;   p_xyz:=randpoly({x,y,z},'terms'=varterms,'degree'=vardeg);   L:=coeffs(p_xyz, [x,y,z], 't');   L1_abc:=[seq(randpoly({a,b,c},'terms'=paramterms,'degree'=paramdeg,               'coeffs'=rand(paramcrng)),               i=1..nops([t]))];   L2_abc:=[seq(randpoly({a,b,c},'terms'=paramterms,'degree'=paramdeg,               'coeffs'=rand(paramcrng)),               i=1..nops([t]))];   L_abc:=L1_abc-L2_abc;   `+`(op(zip(`*`,L_abc,[t]))); end proc: >  gen_p([x,y,z], [a,b,c,d]); >  gen_p([x,y,z], [a,b,c,d]); >  gen_p([x,y,z], [a,b,c,d]); >  gen_p([x,y,z], [a,b,c,d],       vardeg=3); >  gen_p([x,y,z], [a,b,c,d],       paramdeg=3); >  gen_p([x,y,z], [a,b,c,d],       varterms=6); >  gen_p([x,y,z], [a,b,c,d],       paramterms=4); >  gen_p([x,y,z], [a,b,c,d],       vardeg=3,varterms=6,       paramdeg=3,paramterms=4,       paramcrng=0..99); >

Download param_poly.mw

sol := {x=12.0005, y=4.65}:

eval(x, sol);

eval(y, sol);

eval(x^2+y/5, sol);

restart;

expr := (M/(L*T))^a*(M/L^3)^b*(L^2)^c:

ans:=simplify(expr) assuming L>0, T>0:

ans;

               (-a - 3 b + 2 c)  (-a)  (a + b)
              L                 T     M

combine(expand(expr)) assuming L>0, T>0;

               (-a - 3 b + 2 c)  (-a)  (a + b)
              L                 T     M

combine(expand(expr)) assuming a::integer, b::integer, c::integer;

               (-a - 3 b + 2 c)  (-a)  (a + b)
              L                 T     M

combine(expand(expr)) assuming a::integer, L>0;

               (-a - 3 b + 2 c)  (-a)  (a + b)
              L                 T     M

eval([expr,ans],[a=1,b=1,c=1/4,M=1,T=1,L=-2.0]);

               [0.08838834762, 0.08838834765 I]

It is coincidence that op(0,e) happens to be the capitalized instance of the name of a type, for e being of numeric type such as integer, float.

Rather, op(0,e) for such things is the name of a constructor, such that op(0,e)( op(e) ) constructs e itself.

Eg,

op(0, 35.4);
                        Float

op(35.4);
                       354, -1

Float( 354, -1 );
                         35.4

op(0, 35.4)( op(35.4) )
                         35.4

op(0, 2/3);
                        Fraction

op(2/3);   
                          2, 3

Fraction( 2, 3 );
                           2/3

op(0, 2/3)( op(2/3) );
                           2/3

The construction calls Integer( -34 ) and op(0, -34)( -34 ) both produce 34 itself. That may not seem very exciting, but it is consistent with the other examples above.

op(0, -34);
                           Integer

op(-34);
                             -34

Integer( -34 );
                             -34

op(0, -34)( op(-34) );
                             -34

It is not the case that all expressions can be reconstructed like e = op(0,e)( op(e) ), but that is the case for the other types you mentioned: Vector, Array, Matrix, `+`.

Just because there is a constructing procedure that happens to produce an expression doesn't mean that it has to also be a type. It looks like you've simply made an incorrect interpretation of such things.

You might also look at the command whattype .

[edit] I finished this Answer before I saw Kitonum's Answer (which I've up-voted).

So you are using a call to Plotter from the Maplets[Elements] subpackage?

And you tried to pass

display(seq(S[n]$5, n=1..10), insequence=true)

as its first argument?

You could try this instead, as the first argument to Plotter.

PLOT(ANIMATE(seq([op(S[n])]$5, n=1..10)))

[edited] Since you mentioned the plots:-animate command, another possibility for that first argument to Maplets[Element][Plotter] might be something (clunkier) like say,

plots:-animate(plots:-display, [S[trunc(n)]$5],
               n=1..10, frames=50, paraminfo=false)

It happens because the usual evaluation rules (evaluation "up front" of arguments to procedure calls) would be too strong for mutable things like Vector/Array/Matrix which one sometimes wants to be acted upon "in-place".

That is to say, the eval which gets applied to procedure arguments does not have its usual effect on the entries of a Vector/Matrix/Array argument. That aspect is by design.

It gets slightly confusing because the printing mechanism for rtables (Vector/Matrix/Array) does the full evaluation on the entries. But don't be mislead by what gets shown by `print/rtable`. By using lprint we can get a more clear picture of what's going on.

The command rtable_eval does the kind of full evaluation (acting upon elements) that you might have been hoping for.

>  restart; >  v := <a,b>; >  a := 3: b := 4: >  lprint(v); Vector[column](2, {1 = a, 2 = b}, datatype = anything, storage = rectangular, order = Fortran_order, shape = []) >  lprint( eval(v) ); Vector[column](2, {1 = a, 2 = b}, datatype = anything, storage = rectangular, order = Fortran_order, shape = []) >  lprint( rtable_eval(v) ); Vector[column](2, {1 = 3, 2 = 4}, datatype = anything, storage = rectangular, order = Fortran_order, shape = []) >  convert(eval(v), list);   >  convert(rtable_eval(v), list); >

Download rtable_eval.mw

It happens because GAMMA(n,1) is returning a result with exp(-1) rather than 1/exp(1).

The product of terms exp(1) * 1/exp(1) would simplify (even automatically). But the mathematically equivalent product exp(1) * exp(-1) requires an explicit simplifying step such as a call to simplify or combine.

>  restart; >  r := rsolve({u(n)=n*(u(n-1)+1), u(0)=0}, u); >  R:=unapply(simplify(value(r)),n); >  seq(R(i), i=0..5); >    >  S:=unapply('combine'(simplify(value(r)),exp),n); >  seq(S(i), i=0..5); >

Download exp_combine.mw

I started and finished my Answer before I saw vv's fine Answer. I figured that I'd submit anyway (because I had an explanation), while up-voting `vv`.

There are several ways to show that this particular expression equals zero, step-by-step using Maple. Here's one:

>  restart; >    >  ee:=-3*(sqrt(10+4*sqrt(5)))+sqrt(50+20*sqrt(5))+sqrt(10-4*sqrt(5))+sqrt(50-20*sqrt(5)); >  # These are all the terms in the sum. [op(ee)]; >  # Pick one. op(3,ee); >  # Multiply each term by that. map(u->op(3,ee)*u, [op(ee)]); >  # Combine radicals. map(combine, %); >  # Expand the products within the radicals. map(expand, %); >  # These are all the original terms, scaled. op(%); >  # Add them together. `+`(%); >

 

rad.mw

The numerators of the values of A4[3,3] and A4[4,4] are not the integer 1. They are both a so-called Atomic Variable (atomic identifier, or name) that merely looks like a 1.

If I delete those two entries are instead re-type both as -1/TW then the Eigenvalues command returns complex floating-point results as one would normally expect for A4 a floating-point Matrix.

Eignevalues_1.mw

I'm not sure how you managed to get those numerators for be that name (which displays like 1, but which is not actually an integer.) Presumably it was not due to some deliberate action of your own. I suspect a bug/quirk in the Matrix palette (which you appear to have used to get the typeset 2D Input for the Matrix entry). There were some bugs related to the Matrix palette in the earlier point-releases of Maple 2017 (eg, 2017.0, etc). Your attachment was last saved using Maple 2017.3 so I guess you've already updgraded and perhaps there may still be some issues with the Matrix palette. Do you recall doing anything different for entering those Matrix elements?

Here in the attached worksheet is one way, using different names for the 3 points used for each triangle. This way will allow you to operate with the triangles stored as tabl[i] without having to immediately draw them (producing actual, distinct plots right away).

tri.mw

Another way involves giving up on storing them as mere triangle things (rather than as final plots) in the tabl[i], and storing their respective plots instead. (I use a different table name, P instead of tabl, just to make it a little more clear).

tri2.mw

This homework/coursework question has been asked and answered recently by others. See here for one explanation.

I showed a similar thing here, using the events functionality of numeric dsolve.

(I also showed it there using Optimization:-Minimize.)

Every call to DocumentTools:-InsertContent entirely replaces any content in the sole Task Region that an Execution Group can have.

In other words, each time through your loop the InsertContent call will wipe out whatever was inserted the previous call.

You cannot work around this with the kind of looped call to InsertContent call that you have.

You can only work around it by inserting xml content which itself contains all the augmented content.

Eg, hyperlink_do-loop_1.mw

So you can use a seq call within the construction. But you cannot succeed doing any looped call to InsertContent.

You have other choices, about what to enclose within such a seq call. It needn't be of the form seq(Group(Input(...)),...) but instead could be different hyperlinks in a sequence of Cells in a Row, or a particular Cell in each of a sequence of Rows in a Table, or a particular Cell in a sequence of subTables within whatever, etc.