Try passing the option  style=surface  to the plot3d call in question.

(Or, if your Maple version is truly ancient,  style=patchnogrid ).

The visual effect that you are calling "grid" is sometimes referred to as a wireframe. Its resolution details (when present in the rendering) are affected by the choice of the grid option, yes. But whether it appears at all -- or not -- is controlled by the style option.

See the Help page with Topic  plot3d,options  for more detail on the possible values that can be used for the style option.

If you search this site then you can find previous questions with the same topic.

For example, here.

I found that recent item by looking at the questions with the phaseportrait tag. It was right at the top.

There are other ways to search the site. Entering the terms in this sites Search bar produces a collection.

You can use multiple initial-conditions with the DEplot command. There are examples on its Help page.

You could also use the odeplot command.

I'm sure that someone will be quite willing to do all your problems in full (even coursework questions). But perhaps you could also show how far you've gotten so far.

Is this something like the look you're going for? (You can adjust the style, transparency, etc). Q1_ac.mw

If you don't need the solid boundary of the leading side (that moves) then it's a great deal simpler to do. I just prefer this look. I find that too much transparency makes these kinds of rotations overly difficult to visualize (and poorly so).

restart;
Lift3D:=plottools[transform]((x,y,z)->[x,z+sqrt(6-(sqrt(x^2+y^2))),y]):
F:=plottools[transform]((x,y)->[x,y+sqrt(6-x),0])(plot(sqrt(4-r)-sqrt(6-r),r=0..4,
                                                   filled,transparency=0.0)):
P := A -> plots:-display(orientation=[-90,15,-160],
            Lift3D(plot3d([[r,theta,sqrt(4-r)-sqrt(6-r)]],
                   r=0..4, theta=0..A, coords=cylindrical, filled,
                   orientation=[-90,15,-160], lightmodel=light1,
                   grid=[40,max(2,ceil(evalf(49*A/(2*Pi))))],
                   scaling=constrained, axes=normal, style=patch)),
            `if`(A<6.28,[F,plottools[rotate](F,-A,[[0,0,0],[0,1,0]])][],NULL),
            labels=[x,y,z]):
plots[animate](P, [A], A=0..2*Pi, frames=17, paraminfo=false);

This may be similarly resource intensive as an animated use of 3D plots:-shadebetween (for a similar number of frames). I could probably improve it by ditching the filled option in the plot3d call (inside P), and using a grid=[...,2] cylinder instead. That's done pretty well before -- the cylinder shape can have varying height, to joint the two surfaces where they don't intersect within the desired domain. Let me know if memory/GUI performance is a huge issue.

Here is a revision, which works.

I put a few comments into the Action Code, to explain how the substitution (for n) in the formula can be done.

I did not otherwise change the algorithm. It could be done more efficiently. I left it in the spirit of your prior work.

Iterative_components_ac.mw

[Edit] This is better than my original example (which passed n=3.0 and while relevant was not the most precise as explanation). I re-instated this Answer as it was accidentally deleted by someone else.

restart;
Digits := 20:
eval( ((n+1.)/n)^(n+1.), n=3 );

         3.1604938271604938268

restart;
Digits := 20:
evalf( eval( ((n+1)/n)^(n+1), n=3 ) );

         3.1604938271604938272

The difference between seq and $ is one of evaluation. (See also `||` versus cat.)

By the way, in the construction of your a list there is a single call to procedure u, into the result of which are placed the ten different integer arguments. In the construction of your b list there are ten calls to procedure u (each of which applies evalf).

This is difficult to test properly and carefully because of the following:
1) So-called "plot persistance", where an Output region of the GUI retails details of some "global plotting options" unless the output is fully removed.
2) Some additonal ordering issue that is hard to pin down -- possibly GUI internal state.

Having said that... I believe that the problem might be overcome by forcing the order in which the ORIENTATION and PROJECTION substructures appear within the PLOT3D structure.

Execute the following within a completely new and blank Worksheet. Note the use of separate Execution Groups. proj_issue_2019.mw

restart;

# new Execution Group
redo := proc(P::specfunc(PLOT3D)) local s,r;
  (s,r):=:-selectremove(:-type,[op(P)],'specfunc({:-PROJECTION,:-ORIENTATION})');
  :-PLOT3D(r[],:-sort(s)[]);
end proc:

# new Execution Group
P1 := plot3d(x*y, x=0..10, y=0..10, grid=[2,2], projection = 0.2, orientation = [55, 75, 0]):
P1;

# new Execution Group
P2 := redo(P1):
P2;

# new Execution Group
op(P1);
op(P2);

For me, the forced reordering fixed the issue.

However, I found that with sufficient jiggery-pokery-editing-rerunning I could somehow fool the GUI into rendering the previously incorrect plot as OK, even though I was taking care about point 1) above. And I know what I'm doing. Hence I conclude that there is some additional weirdness in the GUI state that can also make it magically appear fixed for all Exec Groups (ie, point 2 above).

I am seeing the bug in Maple 2017.2 to 2020.0 on 64bit Linux. But it works properly in Maple 17.02, 18.02, 2015.2 and 2016.2, in which versions it does not make any difference in which order the substructures appear.

I have submitted a bug report (Software Change Request).

Finally, it appears to not be sufficient to simply switch the order in which the projection and orientation options are supplied to the plot3d command. Sometimes that works, and sometimes not -- but do not be deceived into thinking it is sufficient, because you may be fooled by points 1) and 2) above.

You could look at combinat:-nextcomb.

That allows you to process/walk the combinations one by one without generating them all up front. But it also allows you to choose the size of the set.

If you have an original set of N things which are not simply integers then you can apply the nextcomb command to produce the combinations of the ordinals. You can use that to index into the original set of things, to get the appropriate subsets.

restart;
with(combinat):

S := {a,b,c,d,e,f,g}:

N := nops(S);
                             N := 7

Q := firstcomb(N, 3);
                         Q := {1, 2, 3}
S[[Q[]]];
                           {a, b, c}

Q := nextcomb( Q, N );
                         Q := {1, 2, 4}
S[[Q[]]];
                           {a, b, d}

Q := nextcomb( Q, N );
                         Q := {1, 2, 5}
S[[Q[]]];
                           {a, b, e}

You could also look at the Iterator package (available in your Maple 2017), with which you may get improved performance (of the generator, rather than of what you do with the iterates, naturally). If the cost of what you compute with the iterates dwarfs the generator cost then you might as well use whichever you find more convenient.

I have to state that your "problem" is not something to do with simplify specifically. It's to do with evaluation.

And the behavior is completely normal. Your expression that is assigned to T contains the global l1 and l2 names, and if you subsequently assign values to those same names then it should be expected that any full evaluation of T will result in the values of l1,l2 being utilized. Perhaps you know all that, ok.

Yes, you could pass an unevaluated T into a modified version (using the uneval modifier) of your procedure simplify2 and then evaluate the passed argument only 2 levels. Note that any inadvertant full evaluation of the procedure's 2-level evaluated version of the expression would break the effect.

Note that you could also pass a 1-level evaluation eval(T,1) into your original simplify2 and get a simlar result. But again, any inadvertant full evaluation within simplify2 would break the effect. simplify2_orig.mw

You could also robustify the route of using the uneval modifier, by forcibly replacing all the names with generated locals. In the attached I done that, and made a few other edits. It also shows a few other "length" metrics. cost_simplify.mw

But now I come to my main point. Your Question stated: `The variable "l1" stands for "length 1" in a mechanic problem as well as "length of the expression"'.  The core problem is use of the same global name l1 for different purposes! Don't use the name l1 (of the same scope) within an expression to stand for "length 1" (of a beam or whatever) while also using or assigning l1 (at the same scope) to mean "length of the expression". That is wrong programming. Trying strange programming hacks to work around this fundamental programming mistake is not the right way to go.

I realize that you've supplied a smaller example of your full work, to represent this issue. But much better would be to back up and figure out how to use different names for different purposes.

There are examples of plotting multiple expressions on the Help page for Topic plot.

Here is is with f and df as expressions. Notice that in this case the plot command's second argument is x=-5..5 (ie. name=range).

f := ( (x^3) / (2) ) - 5*x + 2;

               1  3          
          f := - x  - 5 x + 2
               2             

eval(f, x=4);

                 14

df := diff(f, x);

                   3  2    
             df := - x  - 5
                   2       

plot([f, df], x=-5..5);

You could also add various options, for example,

plot([f, df], x=-5..5,
     thickness=3,
     color=["Purple", "Green"],
     legend=['f','diff'('f',x)]);

See the Help page for Topic plot,options for more details.

And here it is below with f and df as procedures (arrow operators) instead. The plot will look the same. Notice that in this case the plot command's second argument is just the range -5..5 .

f := x -> ( (x^3) / (2) ) - 5*x + 2;

      f := x -> (1/2)*x^3-5*x+2

f(4);

                 14

df := D(f);

       df := x -> (3/2)*x^2-5

plot([f, df], -5 .. 5);

The very best way to make progress with Maple is to learn the programming language, bit by bit. It will reward you, going forward, and it will allow you to deal with more complicated examples than the purely "clickable"/tutor approaches could ever handle.

Make sure that you are running the latest point-release for your major version, ie. Maple 2019.2 .

The strange floats in your results hint that your license verification might be having trouble (either a cracked version or a rare false positive detection of such). The later point-release may do better.

This works in Maple 11 (as well as later versions):

expr := -(729*beta*(1/2*(-1/9*(-5/27*beta-1/9)*lambda^6-1/9*(1/9*beta^2*TT+
(10/9*TE+2/3*TT)*beta-1/9*TE)*lambda^4+5/27*(2/5*TT*(3/2*TT+TE)*beta+TE*
(TE-2/5*TT))*beta*lambda^2-1/9*TE*beta^2*TT*(-TT+TE))*p1(m,t)^2+(beta*
TT-1/3*lambda^2)^2*(-1/3*lambda^2+TE)^3*((p2(m,t))/(lambda^2-3*TE)+3/2*(
(lambda^2+TE)*p1(m,t)^2)/((lambda^2-3*TE)^3))))/((3*beta*TT-lambda^2)^3*
(3*TE-lambda^2)^2):

collect(expr, [p2,p1], simplify);

                                       2                  2         2
     3 beta p2(m, t)         (-5 lambda  + 3 beta TT) beta  p1(m, t)
   ------------------- + 3/2 ----------------------------------------
                     2                                   2 3
   3 beta TT - lambda                 (3 beta TT - lambda )

The result is very close to your given target expression, up to the leading signs or the two terms. You gave the target as,

-3*beta*p2(m,t)/(lambda^2-3*beta*TT)                                            
+3*beta^2*(5*lambda^2-3*beta*TT)*p1(m,t)^2/(2*(lambda^2-3*beta*TT)^3);

                                  2          2                      2
      3 beta p2(m, t)         beta  (5 lambda  - 3 beta TT) p1(m, t)
  - ------------------- + 3/2 ---------------------------------------
          2                                  2             3
    lambda  - 3 beta TT               (lambda  - 3 beta TT)

Calling simplify(expr) in Maple 2020 produces a result similar to this next result in Maple 11 (in which version the size option of simplify is not enabled by default).

simplify(simplify(expr),size);

     //                2\2                /          2          \               \                                                                  
     ||          lambda |                 |  5 lambda           |         2     |                                                                  
  27 ||beta TT - -------|  p2(m, t) + 1/6 |- --------- + beta TT| p1(m, t)  beta| beta                                                             
     \\             3   /                 \      3              /               /                                                                  
  ------------------------------------------------------------------------------------                                                             
                                               2 3                                                                                            
                            (3 beta TT - lambda )

Here is something from the first file: Beregningsdokument_ac.mw

There seemed to be something mixed up with the XML Font tags and the Code Edit Region. (You had two copies of the TgPakken  source within it -- I deleted the duplicate which had Font irregularities, as well as a misplaced closing </Font> tag. I'm not sure if it related to UTF-8 and strings in the Code Edit Region, or something related to an attempt at marking up a duplicate copy of the source in the C.E.R.) Please check it.

Here is something from the second: Beregningsdokument_2_ac.mw   It was the same issue, so please check this file.

This problem is not the same kind as in the older Question to which you linked, and not fixable by Joe's procedure in that thread. Also, neither Document is recovered (even partially) by opening in Maple 2020.0.

You might want to make regular backup snapshots from now on.

By the way, you seem to be running Maple 17.00, without the (free) point-release update 17.02.

Your version of the procedure has a line,

    z := `mod`(z^((1/4)*p+1/4), p) = 1;

instead of,

    z := `mod`(z^((1/4)*p+1/4), p);

In other words, your procedure is computing the z values differently. The "= 1" is an accidental typo, in your rewrite.

By the way, why did you change some of the &^ calls to ^ calls? Are you aware of the difference? You might want to read the Description of the mod help page, where there is a bullet point on this.

I don't really understand why you've rewritten so much of the procedure. Would you care to explain why you changed it?

If you do not actually need the intermediate results (with base symbol B) then you can do it all in one shot.

varA := [A[1, 0], A[1, 1], A[1, 2], A[1, 3], A[1, 4], A[1, 5],
         A[1, 6], A[1, 7], A[1, 8], A[1, 9], A[2, 0], A[2, 1],
         A[2, 2], A[2, 3], A[2, 4], A[2, 5], A[2, 6], A[2, 7],
         A[2, 8], A[2, 9], A[3, 0], A[3, 1], A[3, 2], A[3, 3],
         A[3, 4], A[3, 5], A[3, 6], A[3, 7], A[3, 8], A[3, 9]]:

T1 := table([2=3,3=2,5=6,6=5,7=9,9=7]):
T2 := table([2=3,3=2]):

map(u->A[`if`(assigned(T2[op(1,u)]),T2[op(1,u)],op(1,u)),
         `if`(assigned(T1[op(2,u)]),T1[op(2,u)],op(2,u))],
    varA);

    [A[1, 0], A[1, 1], A[1, 3], A[1, 2], A[1, 4], A[1, 6], A[1, 5],
     A[1, 9], A[1, 8], A[1, 7], A[3, 0], A[3, 1], A[3, 3], A[3, 2], 
     A[3, 4], A[3, 6], A[3, 5], A[3, 9], A[3, 8], A[3, 7], A[2, 0], 
     A[2, 1], A[2, 3], A[2, 2], A[2, 4], A[2, 6], A[2, 5], A[2, 9], 
     A[2, 8], A[2, 7]]

You didn't mention whether you needed to have it be highly efficient for case of very long input lists (or if you had a great many examples to process). Also, are all the entries simply the name A, indexed by such a small number of possible integer values?

Alternatively, you might have only a modest number of modestly sized examples, and want the simplest kind of code (that you will understand immediately upon looking at it, years from now, etc).

Here is an alternative (which computes comparitively quickly for your given example),

T1 := table([0=0,1=1,4=4,8=8,    2=3,3=2,5=6,6=5,7=9,9=7]):
T2 := table([0=0,1=1,4=4,5=5,6=6,7=7,9=9,8=8,    2=3,3=2]):
map(u->A[T2[op(1,u)],T1[op(2,u)]], varA);

And even there you could easily construct the trivial parts of those tables programmatically.

The problem is due to numeric issues along the boundary.

In Maple 2017, for this example it is much easier to retain the default grid size and simply reduce the plotting domain by a very small value. For example, plot3d_question_M2017.mw

BW_dilog:= proc(x)
  Im(dilog(1-x))+log(abs(x))*argument(1-x)
end proc:
V:= proc(z,t)
  BW_dilog(exp(I*z))-BW_dilog(exp(I*(z+t)))+ BW_dilog(exp(I*t)) 
end proc:

plot3d( [V,0], 1e-9 .. 2*Pi, 1e-9 .. 2*Pi );

You could try to pass the grid option in your Maple 2017 so that it utilized a much greater number of points (in both dimensions). That would push the problematic boundary and look slightly more like you want, but it would be at much greater computational expense. And the GUI gets sluggish if you make that resolution too fine. Also, you would need to use a very high grid resolution. (Note: it would have to be considerably greater than the [100,100] that Tom used -- his result looks very good because he used Maple 2020, and not because he used grid=[100,100] . It would have to be considerably greater than [200,200] which is similar to Kitonum's numpoints=40000 suggestion and which already takes much longer to compute. I suspect that the problem cannot be effectively and practically solved using a finer grid resolution alone.)

For interest's sake, in Maple 2020 this problem is handled automatically through its new adaptmesh option (true by default). Your original attempt produces the following directly (3D plots are also larger by default in Maple 2020) even with the default grid setting of [49,49]. You could also increase the grid resolution here (and/or use parametric form calling sequence of plot3d), to get even better behaviour along the problematic boundary. And, of course, you could still reduce the plotting domain here too.